It is baseball season and according to some pitching beats hitting every time. In this article I would like to suggest business process beats tool every time.
I have been talking to several potential customers in the last few weeks and it surprises me how often tool is the primary driver in IT decisions. In this post I would like to tell some personal stories about how this has been a bad decision and how we got it right.
In my last job at a very large company my responsibility centered around the projects we were tasked with doing. As it is in all businesses there was a much larger appetite to invest in technology than there was investment money available to support that level of effort. The key to being able to manage this process is being able to compare many seedling requests to each other on an equal basis.
The first group to take on this problem was from our corporate team. They had already chosen a tool that was going to be used for enterprise project management that had some capabilities in demand management. The thought process was to use the tool out of the box. The biggest problem with the tool was not getting the data in, but it was getting it out to be presented to decision makers. There was no good reporting mechanism to support that part of the process and the usage of the tool floundered.
In the next phase of our evolution in demand management a strong leader came along who recognized the tool’s short comings and implemented a PowerPoint based process that completely ignored the tool. The great thing was that this focused us on the steps needed to complete the process and not fighting with a tool. We developed 5 stages of demand management, idea creation, review, promotion, prioritization and approval. These stages gave us the capabilities to compare the demand on an equal basis.
The final stage of our evolution expertly mixed together the tool and the process. We went back to the tool with an understanding of when and where we needed reporting to come out of the tool to support the process. We knew the pain points of running the process by hand. This was mostly in aggregation of the project requests. We took this knowledge and with several configurations and reports were able to build an entirely sustainable process inside our tool. In fact we had such a solid process and tool combination that the next year when a merger took place we were able to swap out the tool in 4 months and have the process up and running for both companies. All of this was because we focused on process not tool.
As I said at the beginning of this post, I have heard several companies say, “My accountant said I need QuickBooks,” “I need to get SalesForce because I used it at my last job,” or “We need to install an ERP because QuickBooks does not work for our size business.” All of these statements need careful consideration. In the first statement the jump from paper ledger books to QuickBooks may not be very easy for the company in question. In the second case I asked the company about their sales and marketing process and the answer was word of mouth and networking. SalesForce is definitely overkill for that situation. I suggested first building out a robust marketing and sales process using a free CRM tool and then growing into a paid service. Finally in the last case the size of business may dictate graduation from QuickBooks, however the more important driver to an ERP needs to be the processes that it will automate. How will it handle order to cash, procure to pay, record to report, and payroll processing? All of these are more important to have in place before trying to jump to an ERP. Many ERPs lie dead on the roadside because the implementation tried to drive the process instead of the other way around.
About the author:
Greg Stellflue is a remarkable Information Technology leader with rich experience in multiple IT disciplines.
Email: [email protected]
If you are interested in a free assessment of your IT or just coffee sign up below.