I ask you, how can you know where you are going if you don’t know where you have been?  Do you know who is doing what and what role that is in the organization no matter who sits in the role?  Do you know where your manual processes are and how you might achieve efficiencies with system support?  Do you know what rules are necessary to ensure when you follow the process that you are in compliance?  Are you aware of the boundaries and how the HR process may be impacted by the Recruitment process, or how the supply chain process may be impacted by procurement. 

It is always amazing that there is someone who indicates process is not important, or we don’t need to do that until we get into designing the system and writing the specs.  Process Analysis needs to happen up front to determine where the opportunities are for change, how change will be instantiated and communicated, what training will need to take place, does the system support the process or not?  Are there other systems that are integral to the process?

Here are some questions to ask yourself and ensure you have the answers and your processes analyzed to provide a framework and foundation for everything else in your implementation.  The foundation will be there for testing, training, security, roles, compliance and ultimately change and communication. 

Questions;

What is the purpose of the process, outcome and result?

What are the Roles and how will they change?

What are the steps?

What are the business Objects?

What are the rules?

What is manual and where does the system support the process?

What training and testing will be necessary to ensure the process is working as planned?

What are the boundaries between processes and what is the impact on pre and post process?

How will all the changes be communicated and managed?

So if you think process is not important, look to those implementations where you have been involved and determine points of failure.  And on those that were supported by Business Process or Use Case Analysis how they had an impact on success. 

I remain amazed that there are still consultants and professionals who do not understand the value of understanding and anlyzing process at the beginning of an implementation…not in design, not in construct, not in transition, not in deploy but in the beginning to provide a foundation for all stages, phases and tasks involved in an implementation.

I am always amazed when I hear someone say, we don’t have time to plan we just want to get to the results.  I think clients are often frustrated with planning because consultants have used planning to use reams of paper and loads of time developing documents that are never used after the initial stage of the project.  The heavier the document, the more successful the project right?  Planning doesn’t always entail documentation to max.  However, if you aim at nothing….you will definately hit it.  You must aim at the result you are seeking to achieve and planning helps identify that result.  What many clients don’t realize is something can be done quickly if it is well planned.  Training programs are often part of an implementation that are developed quickly, some are effective, some are not.  The ones that are successful are those that are well planned and meet the needs of the client.  They can also be completed quickly if you have a method to follow.  We think of methodology in terms of implementations, but methodology has the root method which applies to every aspect of a project we undertake be it implementation, testing, training, or development.  There is an old Japanese proverb that I think of whenever I hear that planning is not important: ” When you’re dying of thirst, it is too late to think of digging a well.”  Don’t get to where you are dying of thirst in any aspect of your undertakings.  Plan and you can achieve results quickly.  Eliminate the reams of paper but don’t eliminate the planning.