by Tobias Lekman, 12 February, 2011
Image via Wikipedia
The scenario: I have been asked to quote for or implement an IT system or application with specific requirements from a customer.
When tasked with providing estimates and design suggested solutions, it is too easy to focus on the technology and the software instead of the actual problem. Sure, you have years of experience managing and implementing solutions in SharePoint/Dynamics AX/EPi Server but before you start to shove your one-size-fits-all down the neck of the client, ask yourself: what is the supporting business process?
We should assess and identify the business process(es) that the IT system will support. If the process is ill defined or non-existent then you have poor conditions for success.
We have excellent tools available for mapping processes, such as UML and modeling diagrams as used in Microsoft Office Visio or in Visual Studio 2010 for Architects.
Use cases, sequence diagrams and declarative workflows with swim-lanes are all excellent for mapping processes, but they must be verified with the organization to ensure that they are actually in place. A process or policy that is not followed will not be adhered to any better with an IT tool that supports the badly adhered to process! Therefore, never discuss technology during process workshops and always focus on the users day-to-day tasks that align to that process.
Pictures showing use case and sequence diagrams. See “User Requirements Modeling with TFS 2010 for Scrum Backlogs” for more information on the topic.
When the business processes are identified, we can review them and map these to proposed system/application solutions using Gap Analysis or a mapping workshop. This may prove that by making small changes to the current business process we will adhere to a more industrialized process that is readily supported by existing systems. This is a difficult balance and any such decision must be supported by the business, understood and implemented enterprise wide and should not be approached without proper caution.
A common problem is going from heavily customized and bespoke software to industry standard applications and this transition can be extremely painful for the organization unless the core business processes are reviewed and a proper change management program is in place.
There are many good and bad examples where businesses have changed their processes to accommodate more industrialized or streamlined processes and there are several references to companies who have gone under while implementing Enterprise ERP systems.
A good success story is Volkswagen who championed a new organizational IT structure to use resources more efficiently and used this project to reorganize business processes.