Monday, April 12, 2010
What’s the point of the software demo?
I attended a program presented by a local Microsoft partner this week. The partner did a very nice job of hosting this presentation; rented a very nice meeting room at a local restaurant, spent a ton on food, had Microsoft representation, gave away a nice door prize. Attendance wasn’t quite what they wanted but it was still a nicely attended event. But I think they missed an opportunity to make the needed impact on the attendees to move them forward in their software selection process.
Microsoft sells four ERP packages under the Dynamics brand and each product occupies a certain niche as explained by this partner: AX is the high end package, NV is a mid-tier product that is easily customized, GP is another product for mid-sized companies that have both distribution and manufacturing requirements and SL is for companies with project management needs.
Each product was demonstrated for 30 minutes. Each demonstration focused on the role-based model that Microsoft has incorporated into their software. Users are assigned a profile based upon their role in the organization and each role has a set of tasks already configured so that the user can be more productive more quickly every day. Each user can customize their start up screen with menu options, alerts, fact boxes and fast tabs. Great – but did I have to see the same thing 4 times? Did 75% of the time have to be devoted to showing the same functionality again and again?
This brings me to my point – what’s the point? What do you need to see in order to decide that this software package could/should be considered by your company as a potential solution? Is it replenishment? Order processing? e-Commerce? Make a list of the business processes that are critical to your business and communicate that to the software vendor. Reporting, Dashboards and Business Intelligence are the whip cream and cherries of software demos. It’s sweet and looks appealing but not very filling. Make sure you know what the point of the software demo is before you invest your time and the software vendors time.
Monday, February 1, 2010
Documenting Your Current Process is a Waste of Time and Money
Documenting your current processes can be a waste of time and money.
When we are preparing the project plan for conducting a selection project, one topic that is always discussed is whether the client needs to document the existing processes before starting the selection engagement. We believe that the answer to this question is “NO”. Let me explain why:
Our research indicates that clients who engage us to assist them with a software selection have know for at least two, and more likely three years, that they need to replace their software. The decision to replace software requires a significant amount of time and money.
During this period of dissatisfaction, various workarounds are added to address the weaknesses of the system. This includes external applications that are bolted on or developed in-house, applications that are purchased and not integrated, workarounds developed using Excel spreadsheets and more. In other systems we see comment field crammed with actionable information since this is the only place that users have for storing this important information. Unfortunately, if users have not read these instructions or follow the instructions errors will occur in handling orders. To prevent this from occurring more ad-hoc systems or procedures are implemented.
Investing significant time and money in documenting and flowcharting doesn’t result in a better set of requirements. At the Brown Smith Wallace Consulting Group, we have developed process outlines that reflect the standard process flows that the most new ERP packages will follow. We use these outlines to conduct interviews with groups of users to aid us in developing the requirements for a new ERP package. Typically users like to tell us what their software doesn’t do and how hard it is for them to get the right job done on time. These process indexes help us to keep the focus on the process and not the flaws of the current system.
Having a flowchart of the existing system only helps us to understand how dysfunctional the existing system is. It doesn’t help create the vision of the future state of the business. This doesn’t occur until they see demonstrations of new systems and the capabilities that are available to them. Only then can they start to understand the value of the new processes incorporated into the new software.
So if you know your current system needs to be replaced, start by documenting the requirements to achieve the future vision and do not document the past that you want to replace.