General Consultant Discussion

I have had two decent sized customers lose CFO/Controller for an extended medical absence recently. Which leads me to wonder whether any of you have gotten involved with customers in providing documentation for their systems beyond the typical cheat sheets that we often write up. One of the customers is heavily involved with Accellos and a great amount of knowledge was stored in the CFO's head about resolving error conditions, etc. Most of this is admittedly solvable by going directly to the vendor support. I'm curious if there's any way that we can become involved with customers by providing them with some type of ongoing documentation. Sadly, my hunch is that much like disaster recovery most customers won't see the need until they see the need.

You can easily turn this question inward and ask ""what happens if your company loses a principal employee""?????

We could tell a thousand such stories. It's the old Mack Truck theory: Anyone could get killed going home today if they got hit by a Mack Truck. You're right: Nobody sees the need until the need arises. It's one of the reasons some companies simply won't do business with a one-man shop. If YOU are the business, you may not be a viable candidate. Fortunately, we do have reserves in the form of Sage, other resellers/partners, etc. It's an element that should be included in all disaster recovery plans.

We have done some extensive custom documentation over the years, but only when the customer is willing to pay for it.

I took over an account a couple of years ago that was on 3.74 SQL. We just went live on 2014 premium this year. They have extensive custom programs.... at least 50, probably more... SQL triggers, stored procedures, VB Programs, Sage scripts, lots of custom Crystal reports. The CFO / Office Manager is the only person that knows anything about the programs. She will tell everyone, including management that ""everything is documented"". Her idea of documentation is the name of the program, where it resides on the server, and how to run it. I have explained to her and the rest of management that this isn't documentation. Documentation is a the detail, a user manual, that ANYONE should be able to read and then navigate and use the program. I made a big judgement error when I didn't insist on an extensive needs analysis prior to quoting the upgrade. Most of the code was a complete re-write, requiring the programmers to pour through someone else's code to determine the functionality. The Crystal reports had hundreds of hidden formulas, many quite complex that had to be converted from v3.74 to v5.1. One of the best laughs I have had in a while when she asked if I could change the Crystal report to dynamically display customer numbers on the pick screen. I said of course, it is an easy change. She said in the ""old MAS"" it used to look different but when you added or deleted a customer, the pick screen customer list in Crystal would also change. I told her I am not sure how the previous consultant did that in Crystal and she said that looking back at her notes they used a ""VB wrapper"". How in the h#$% am I supposed to know ahead of quoting an upgrade that the Crystal reports are using VB wrappers? LOL!!!!

We were requested to do documentation and process flow for a client about 9 years ago and they are still pulling it out and using it. We do suggest this to our clients and occasionally they request that we document some processes. It is helpful for us as well at them.

@DougHiggs I had a somewhat similar customer (since sold out to another company). They originally purchase Sage from someone who was apparently a master developer. It appeared multiple people were involved with the implementation. When the ""Crystal person"" was implementing they created quite a few custom Crystal forms. When the ""developer person"" was in doing the implementation they hard coded lots of reports and options. Needless to say once they got rid of the old consultant they were surprised to find they were essentially stranded at their current release unless the re-did a significant amount of the prior custom work.

Yes, that is a similar situation. This company was stranded for several years. They went live in August and everything is stable on v2014. I am very happy the upgrade is behind us.

I'd like to see enforced standards for master developers, so customizations are fully documented and designed to allow upgrades. That was the original ""promise"" of business framework, but it does not prevent developers from directly customizing code. I would suggest Sage be the enforcer, but they have a hard enough time just running their business and keeping management and staff.

For a brief period of time Sage seemed to have a cogent plan for how Sage 100 would become much easier to upgrade. Then as product managers came and went so did those plans. It's too bad because with just a little more effort I think Sage would hold onto more of their installed base and maybe even gain some. The depth of the third party ecosystem is an asset that a lot of newer ERP doesn't yet have.