fryeguy

Does anyone else find the change order generation process convoluted at best?

Let me tell you how I think it should work, then describe the concerns I have with how it works.

Steps to complete a CO:

1. Choose two Project Revision to compare. Click Run.
2. In the window, the following data returns.

a. At the top, an overview of the changes in the same format as they show today.
b. Next, Equipment and Labor items including accessories. Just the way it shows now.
c. Packages are last (although I don't find the order so important).

3. Here is where it gets good: by default, all items are selected.
4. Now I can simply click on reports and choose the report I want to run. At this point, the report will actually run with no question asked.

D-Tools: clean it up and do us all a favor.

Here are the things I am confused by:

1. Who cares about the "project overview" of the change?

- OK, so add the project overview for the change, but make it like a header in the window. It is only informational since you can't really do anything with it. So it is good to have. But don't make the user take extra steps to get beyond this point.

2. Why do Project Overview, equipment and labor, and packages need to be handled separately with a drop down menu?

-Like I said, make the overview a sort of header in the view, followed by equipment, labor, and packages. It is OK to show that a package is a package, but why add steps by having the View drop down?

3. I don't want to individually pick items, whether separate or packages, to run my CO. It is possible that in some cases I will want to deselect an item but it is certainly the exception not the rule.

4. Once I chosoe all the items and click to run a report. Don't pop up another dialog that is basically the equivalent of an "Are You Sure?" message. If I didn't want the items I would have left them out in the prior step.

5. If someone wants to spend time on all these other choices and clicks, then by all means give them the options. I cannot see any value here in all the extra clicks, options, and windows popping up. Some of our other users refuse to run CO reports because the interface is so bad.

JordanC

You have some good points. But, IMO, this is an issue that I have not wasted a minute of thought on. I guess I do not find it being that hard to generate? I think that this would go hand in hand with program design and operation consistency. Which I do have problems with, but I forget about when I come across errors and issues that are of higher value to the operation of my daily tasks.

__________________

Space available for rent.

fryeguy

I do agree that the current process doesn't stop me from performing change orders.
It does however make little sense. I'm sure there are some reasons why the change order interface is built this way. However, as a company we are constantly looking at how we can improve our processes and procedures with a vision for scalability. When a key piece of software has features that are not intuitive it is important to explore better options and help the software company make a better product. I know the folks at D-Tools are sharp, and they have created some really valuable software, but they have a view of the software they create from two perspectives; one is the equivalent of looking at earth from space, the other is like exploring an underground cavern. Both of these views can tell you something about the earth, but neither perspective will tell you everything you need to know. So users like us must give our insight if we expect changes to the tools that our businesses rely on daily.

JordanC

Originally Posted by fryeguy

So users like us must give our insight if we expect changes to the tools that our businesses rely on daily.

Not disagreeing with you. I was just trying to say, if I have a list of problems, I am going to solve the ones that cause me the most trouble first.

__________________

Space available for rent.

CoreyK

fryeguy,
I have been following this thread and wanted to take the opportunity to address your requests and, hopefully, provide some insight into where D-Tools stands on this feature set.
First of all, your specific points:

1. The overview information: The Revision Management tool was designed to provide a number of features to users, one of which is change order generation. The overview is designed to give users the ability to deeply inspect variations from version to version. In part, this was designed to help spot changes, especially to global or phase setttings, that may have accidently changed. Since this feature has been released it has become apparent that this is not as usufull to users as we thought. Clearly the focus here should be on managing change orders.

2. Handling Packages Seperately: Unfortunately this just comes down to equipment, labor, and packages being structured differently. The difference required a different display. I am sure we can think of an easier way to toggle these displays or combine them. I will add this request to our feature list.

3. Selecting Items: This is actually an interesting issue to discuss and has alot to do, believe it or not, with the underlying goal of the Revision Manager. First of all, though, the Select All and Deselect All features were added in a recent dot release to provide this functionality. But, why are not all items selected by default? In the many conversations with partners, team members, and customers it was communicated to us that in many cases not all items that are changed are placed on change orders. While this doesnt sound like your buisness process, we wanted to make sure that users that identified "internal" vs "external" changes were able to manage items individually. The difference between these two types of changes is simple: External changes were changes that the customer needed to sign off on. Internal changes are those that impact the cost of a job (say a change in the item cost) but did not impact the price or requirements of the job the customer had agreed to.

This bring me to the next point about the revision manager, a good deal of functionality here was designed to help manage changes between revisions. This gives the user the ability to create 3 different types of revisions: Estimated, As Sold, and As Built. The Estimated is the job the user agrees to, the As Sold (which starts as a revision upon the agreed estimate) includes changes to the job the customer agreed to after work has started. The As Built includes all changes the customer agreed to, as well as changes to cost or labor that came under or exceeded the estimated -- consider this an actual. Using the Revision Manager's Manage Changes features can be used to create a set of revisions that give users the ability to see the varience between their estimate, the resutling sales, and the resulting cost of the of the job. Since different changes are treated differently, the ability to manage these items individually became that much more important.

4. Confirm Message: I agree this is probably more cumbersome that neccessary we will add simplifying this as a feature request for a future release.

All that explaination aside, I agree that this interface can be improved and the process/benifits/usuage/usefullness better articulated. Improving this process has been and still is very high on our list of priorities. We realize this is an area of great importance to our users and we can do a better job here.

Each release we do contains a combination of new functionality and improvements to existing functionality. We are in the habit of laying out these requirements atleast one release in advance. So while we are working on a release currently, a list of objectives for our next release is allready being formed.

I can tell you that improving this feature is very high on the list of priorities for the release following the one we are currently developing and testing. The scope is still being defined, but I would like to make sure improvements such as persistant storage of change orders, better reporting, and export to outlook (invoices and credit memos), for instance, be central. I will add your suggestions here and place an emphasis on overall usability. I would also be very happy to elicit your feedback directly -- I do believe that our customers know more about what is correct functionality than we do.

Lastly, there is another way to generate change orders that you may find faster and easier to generate. A change order report is essentially a proposal report with the word Change Order placed at the top. Using the report designer you can quickly use the proposal report as a template to create a change order report (usefull tutorials on this are available via the report center start page ). In the report center you can run a delta against your two revisions and run the change order report against the resulting delta. This is effectively how the revision manager works with the additional behavior of being able to select specific items - the reporting center will return all changes in the report.

I am not sure this fully addresses your concerns, but I thank you for your feedback and your patience as we work hard to deliver better software.

Thank you

Corey Krehel
CTO, D-Tools

fryeguy

Corey:

I certainly appreciate your detailed response to my posting. Your comments make sense to me and I understand how difficult your job is. SI5 has come along way and we are happy to support the product. In the last six months we have seen great improvements in our ability to sell jobs with all cost factors accounted for, manage our purchasing, handle time management more effectively, and create accurate change orders in a timely manner. This has made my job easier.

Here are my comments on your points:

1. I agree the focus is on change orders. Maybe the overview could be a button next to the reports button. If you need it, you can find it.

2. I reviewed the equipment/labor vs. package viewing idea. Now I see what you mean. I still think it is valuable to have both on screen at the same time. It is pretty easy to forget to change to packages and miss a valuable item. In user interface design, I always feel like less is more. I have worked for Autodesk for almost ten years beta testing several of their products and have spent a great deal of time working with the Human Factors team on UI. Great software really benefits from great UI. I'm sure I am preaching to the choir seeing as SI5 has great improvements over previous releases.

3. I understand your comments on Item 3, however I bet if you took a poll of all D-Tools users you would find the majority run change orders on all items on the change more often than not. I say build the UI to cater to the majority and let the user Deselect All or deselect the items they don't want. If you find that most of the time users are creating change orders where they need to be able to break up the changes, I think you either have users who don't manage jobs well or don't know how to create reports to filter items correctly to get streamlined change orders. I think the concept of managing internal vs. external COs by simply choosing which items to include or not include is a dangerous endeavor. It works but is certainly prone to falling short due to user error.

Now on to your point about "persistent storage of change orders" and other comments related to this. This sounds like a great idea. If I understand you, I assume you mean a change order can be tracked over time in the system without having to track down a PDF report or hard copy.

I have in the past, commented on the "Save Revision" functionality. I also believe this can be improved. Give the user control over revision numbers and the ability to create options with a "Save Option" feature so that different options may be presented without each option showing as another revision in reporting.

That's it. Thanks again for taking the time to review and comment so thoroughly.

Kevin Frye
SoundVision