Success is the goal we all strive to reach!But, what is success?
Is it on time, in budget delivery? Is it being able to tick off all the items on a requirements list? Is it that the systems actually function? Is it ease of use? Is it a high score from a customer focus group? Is it lower cost?
And the “Is it?” list goes on and on.
The answer, at least when it comes to BPM projects is anything but simple. Why? Because BPM solutions are not about simply building a new application, or about improving some application, or even combining a few steps to streamline some work. BPM is a collaborative undertaking. As such it involves people from the business, IT, partners, and manufacturing production - and the customers. That really does complicate things – including the concept of success. Who do you please and what does that take?
The fact is that if you ask the different groups involved in a business transformation, business improvement, or continuous improvement project, you will get some overlap but you will also get very different answers. It all depends on their point of view, what they believe they need, and how the activities affect them.
So success isn’t simply providing a solution that delivers all the tech requirements on the list.
The reality is that success must be viewed from four perspectives – some of you may even add more. But, the recognition that BPM requires much more than the delivery of an application that ticks off all the requirements, is critical. The four perspectives are:
- Technical view – does the solution deliver all the requirements on the specs list?
- Business user view – how well does the solution improve the business?
- Interface view – do all the business and technical parts of the solution work well together?
- Customer view – is the solution easy to use and provide good functionality?
The technical view
The technical view is related to the delivery of application and manufacturing production changes that support the specific needs of the requestor as defined in the business requirements and then translated in the technical requirements. These requirements form a list of capabilities that need to be provided. A comparison of these capabilities against the current ones for the business area gives the delta and points to the improvement.
However, in most cases this list of capabilities does not specify how the requirements must be fulfilled. The design of these changes is thus often the responsibility of the technical staff.
In many companies these requirements are identified by an IT analyst asking the business user or production manager what they need or how the support they are currently getting should change.
The general requirements (i.e. must meet these compliance requirements) and specific change requirements(i.e. the new design must deliver X, Y, Z KPIs) are used as the foundation in creating the new business operation designs – when filtered through the constraints on the design options (usually technical IT and/or manufacturing, or timing constraints). These new business designs must meet the business requirements; leveraging operational streamlining and IT support change. This defines the new or changed business capabilities and how the operation will deliver them The delta between the old and new business models gives a list of business changes – requirements for the creation of a new process or workflow (along with IT and other needed support).
This is the foundation for the definition of changes to IT support. The IT applications analyst then translates these business requirements into tech requirements describing how one or more application systems should be changed. These are the technical specs. When done right, these tech specs align to the business change specs and thus the new business model. These tech specs describe changes to application functionality, data capture and use, etc. – very different from business change specs. The project’s programmers follow this list of capabilities to build new applications or modify ones in use today.
Together these business and tech requirements define the changes that will drive the creation of a solution – changes to the business, production operation, and supporting applications. The combined list of the business, production, and tech requirements produces a check list against which the new solution can be measured – it must accommodate all of the requirements, and deliver the desired KPIs and other defined improvements. When all the items on this check list are tested and certified, the solution is complete from a technical standpoint. This makes the solution a technical success.
The business user view
However, delivering all of the changes from either the business or the technical specs does not guarantee that the solution will actually improve the business operation. Any requirement can be delivered through a wide range of changes. Some of these changes will be beneficial, but others may actually hurt the efficiency of the workflow. When this happens, the solution is a technical success but a business failure.
If the company has adopted Enterprise Process Management, the business view will start at the end-to-end process level and include a cross organization, cross functional perspective on change. Here change is made to process and filters down to the different business operations in the process. These changes are made to improve the entire process and care needs to be taken to look at these changes at both the process and individual business unit levels.
If the company is focused at the business unit level and views the operation from an organization perspective, the view will focus on a given business unit and how it operates. Here, the goal is to improve the activity in the business unit – not in the overall process.
In making these changes at either the process or the business unit level, it should be remembered that work can be performed in any number of ways – all of which may make sense, but only some of which deliver effective and efficient work and workflow. Business managers will most often look at any change in terms of making the operation faster, cheaper and better – less waste, less error, more streamlined, less expensive, more scalable, etc. If the change does not deliver actual, measurable work improvement it will not be a success. If the change requires the introduction of manual work (white space activity) to get around system deficiencies or holes in the activity flow, it will not be a success. And, if the change increases variability in outcome, additional error correction work, etc. it will also not be a success.
Any business improvement related change solution will thus be viewed in terms of helping the way the business works. Any solution that delivers capabilities in a way that fails to improve the way the work is actually performed or that makes the operation more difficult will be considered a failure – even if it clearly delivers every requirement on the spec list.
However, unless success has been defined clearly, in measurable terms, determining if a solution is a business success will be a matter of opinion and opinions may vary widely. Having success determined by opinion should be avoided if at all possible. Also, it is difficult to produce a solution that really helps move the business operation to an optimal state if the business managers and staff are only marginally involved. So, it is important to formally define what it will take to have the solution declared a business success before the start of work – in the project setup activity. It is also critically important to have the necessary level of commitment and involvement at all needed management levels. This will require a well thought out needs analysis at a detailed level and justification for the time and resources that will be needed.
The interface view
Any solution today that affects more than a single application system or a very narrow slice of the business operation will require either new application systems or changes to current applications. Both of these options will likely require new application system connections or modifications to existing connections. These connections are through software interface programs. The interfaces can be extremely complex and represent the greatest potential for catastrophic level failure. The reason is that in addition to adding to the complexity, data transforms as it moves and can be expected to change as it hits each application it flows through. Any failure to move the data correctly, reformatting it as it moves to numerous places will cause either the move to fail or corrupted data to be added to target applications and their databases.
This new activity flow and the accompanying transformation of data must be understood and modified as needed to deliver accurate data to wherever it needs to go. If this fails, the ripple of the problem may impact data integrity and cause serious damage. Care in identifying, defining and building or modifying interfaces is thus critical to the success of any solution. Testing here is critical to success.
As with all of the perspectives of success, this view is important. However, in the other views the solution can limp along while it is being improved. The failure of an interface is different. There is no limping along if an interface fails. Failure in this view requires solution shut down and data backout for anything that may have gotten through. For that reason, ensuring success in this view cannot be optional – even a partial success is a failure.
The customer view
In the end, everything comes down to the customer experience in dealing with your company. If the experience is positive the bond grows stronger and the customers will return in the future. If the experience is uncomfortable, confusing, slow or cumbersome, the customers will leave and find a site at a competitor that may be easier to use. A customer’s impression of the interaction is thus important and must be considered in identifying project and solution quality and benefit.
Keep in mind that many companies will have more than a single kind of customer. This means that personas must be defined and interactions viewed from the perspectives of each persona. Focusing on a single persona is potentially a problem as it may produce solutions that impair usability for other types of users.
In addition, the advances in social mobility computing have set high expectations that are growing daily. The buying public is now computer savvy and the new generation is more than computer literate – they are power users who have much higher expectations than those in companies who use outdated technology every day. But, that too is changing with advances in business process management tool suites and in both mobility technology and “social apps” that are beginning to go far beyond the capabilities that Captain Kirk had available on the Starship Enterprise.
Because of these and similar technologies that are easily available to everyone, expectations from the customers in interacting with your company are constantly increasing. The result is that companies must now live with the changes they started in the “self-service” movement. But, can they? Time will tell who can really architect the IT portfolio and infrastructure and move the archaic technology platforms in many companies into the modern age of rapid change. However, the reality is that most companies struggle to keep up with or support the rapid pace of mobility device and app evolution. This makes the focus on customer viewpoints critical.
The fact is that it is easy today for a change in the operation to result in a ripple that negatively affects the customers. Both solution and customer experience testing must thus produce a collaborative interaction that helps the project team understand the customer viewpoint and what will provide the “Wow” factor - in the customer’s opinion. Only with an iterative approach based on these customer reviews can success be achieved in this view.
Real success is not simple any longer
If the definition of success for any of the project participants is “it depends” or “I’ll know it when I see it”, the project is doomed. This is not a silly concern. I run into it fairly frequently. Why, because people have a need but cannot really define it or how it will change their operations. They simply know they have a problem, a need to improve, or a need to accommodate a new compliance requirement. So, it is up to the project manager and team to work with the business area managers and people to define the change and then to define how success will be measured, what a successful outcome will look like and collaboratively get all who are affected to reach consensus. Without this, the team is shooting with a blindfold on in the solution’s definition and construction.
As if this cultural issue was not enough, success today must consider the capabilities and constraints of the IT environment and the way it has evolved in the past. Applications today are mostly a maze of changes to changes that were never well documented. This is really true of all applications. Often an IT environment may have hundreds of databases and a great many unsynchronized data element definitions and formats. This requires both the construction of unique interfaces (ways of moving data between applications) and the transformation of the data as it moves between applications. Given the maze of application interfaces that exists in most companies, this is an area of change that causes a lot of risk and cost. If not well done, data corruption in multiple databases could cause some serious damage.
Without question, the IT side of any solution is extremely complex and difficult. But, even when that part is done flawlessly, the solution only gains relevancy from its impact on the business operation and through that, the customers – nothing else matters. To get to the changes that thus give any solution relevancy, it is critical that the business and the customers be viewed as active participants in the project and their perspectives be considered as the driving force in any solution. Solution success thus clearly requires successful outcomes from the perspectives of the customers, the business, the creation of capabilities that meet requirements and interfaces that function well while causing no harm to other applications.
As always, I hope this column made you think about your projects and change in your company. Please send any comments or questions – I always like to hear from my readers. Dan Morris daniel.morris@wendan-consulting .com . I would also like to thank Rod Moyer who is indispensable in debating ideas and the opinions in my columns.
Also, be sure to check out Jim Sinur’s blog at http://jimsinur.blogspot.com/ . I think you will find it interesting.
0 comments:
Post a Comment