17 November 2008

What I Learned On My Vacation Away from the Office (DevLearn 2008 #3)

I left DevLearn 2008 on Friday and managed to take the weekend to spend with friends and family instead of working, which I usually do. The advantage to removing myself from work and work focussed topics is that I had time to reflect on the workshop and sessions I attended, as well as reflect on my experiences at DemoFest, which provided an enormous amount of food for thought. DemoFest was an incredible experience. I have not participated in anything like it before. The hall contained easily 20 tables maybe more, I'm not certain. On each table were computers with various kinds of online training samples that were created by elearning professionals, many of whom were employed by companies that wanted the content for compliance or skill development or technical training purposes.

One of the most sophisticated uses of elearning that I observed was designed to train salespeople in the pharma industry about compliance issues. The simulation had the learner "travel through" a week in the life of a pharmaceutical sales representative. It included typical received e-mails, conversations with physicians, managers, and co-workers. The level of detail and complexity of this training was impressive. It was very easy to gain a sense of the subtle and complicated ethical challenges that occur daily in this field of work. In addition, the learner was given the opportunity to experience the consequences of good and poor decision making.
What became apparent to me as I watched this and other demonstrations and training samples at DemoFest was that enterprise software training as it is currently delivered through online channels IS BORING and nearly mind numbing.

I thought back to the classroom training I had observed over the years with enterprise software. One trainer, I recall, staged "Family Feud" contests to help students remember what they had learned during the sessions. Another trainer sang Mr. Rogers' "Welcome to the Neighborhood" with special lyrics talking about the enterprise software. I remember still another trainer letting her students make "wrong" decisions and choices with exercises and lab sessions in the classroom and use the consequences to teach them how to fix errors in the software system. Bottom line these gifted trainers had the ability to make learning about enterprise software - FUN!

Aside from one very savvy client, I haven't heard anyone in the enterprise software arena use the words "training" and "fun" together. The expectation is that a company's users are supposed to understand that this mission critical software is vital to the organization's existence, and that should be motivation enough to get them online or in the classroom to learn the new business processes and application mechanics. This is serious business and we are supposed to be serious about it, right?

The challenge is to find a means for creating online asynchronous training sessions that engage learners in a similar fashion as those gifted trainers without "breaking the project budget" for the implementation or upgrade.

If a plant manager could "take a walk through his day" with the new business processes and applications to get a better understanding of what he will be doing when the new enterprise software is "live," how well would he appreciate the changes? How well would he retain the information? How motivated might he be to change his behavior?




13 November 2008

DevLearn 2008 #2

There is nothing like attending a conference and wishing that you could clone yourself!

Yesterday at DevLearn 2008 was like that for me and today's sessions look to be just as compelling. In the afternoon, I attended a session where the presenter discussed his view of training's purpose - to teach and embed behavior change. In addition, he discussed training in terms of a business function and a process. Then he continued his presentation by talking about why and how training efforts failed so miserably in fulfilling the promise of creating business value. He certainly started me thinking about all the times I've watched enterprise software implementations address the business process transformation and automation issues without the consideration that the education and training around that effort is also a process that must deliver business value.

Another presentation I attended was more a demonstration of various learning technology tools and how they are being used, very creatively, by the Department of Defense. I saw a field treatment guide for a non-medical soldier on an iPod. Literally all the soldier had to do was look at the image of a clothed body on the screen and touch the portion were an injury occurred. The iPod application launched a series of questions that, when answered, guided the soldier to a solution for addressing the problem in the field until medical assistance could be found, simply amazing!

Finally, some of you who read this blog know that I wrote a white paper earlier this year about rapid elearning development tools and their appropriate use in enterprise software implementations and upgrades. Many of the tools that I covered in the white paper have users and representatives here at DevLearn. Needless to say, I have been collecting feedback and stories from users and product direction information from the company representatives so that a new, updated edition of the white paper should be ready in January 2009.

12 November 2008

DevLearn 2008

I have taken a small break from chapter writing to rediscover what is happening in the world, especially as it pertains to training and performance issues. So here I am in San Jose at DevLearn 2008. The entire conference is focussed on Web 2.0 applications and their usefulness for performance support and learning.

All of yesterday was spent in a seminar about using Second Life (an "open" virtual world - anyone can join) as a tool for engaging learners in change, performance support, and training.

I know, I heard those stories too about 2nd Life being used for all sorts of nefarious endeavors, and such. Did you know, however, that Princeton, Stanford, Elon, and San Jose State have sizable presences in 2nd Life? In addition you will find Coldwell Banker, Sun Microsystems, and Intel. What are they doing there? Yesterday I found out.

They are using Second Life to have classes, interview applicants, onboard new employees, conduct meetings, deliver training, and that is just the beginning. I even found a hospital that is experimenting with 2nd Life as a communication channel.

OK why does this matter?

Virtual worlds offer the possibility of a richer and more retentive learning experience than what we have today. Imagine having the ability to take a new employee on a tour of your company's facility or learning about steel production (and visiting a blast furnace) without OSHA concerns or learning about how your organization will function in the future due to business process transformation. All of these scenarios are feasible in a virtual world.

I am excited about how virtual worlds could change our thinking about organizational change, business process transformation, and training. What about you? What do you think of virtual worlds?

Second Life

DevLearn 2008

Stay tuned for discoveries that I make during today's sessions!

09 September 2008

Project and Resource Planning

Throughout more than 15 years of consulting I’ve come across consistent issues during project planning. One of them I would like to address is project resource planning.

Perhaps you are running an ERP project implementation. Maybe you are running an internal IT department and you have a new requirement, which comes from your company's CEO or from your consulting Sr. Vice President or from the Senior V.P. Client Sponsor. It is mission critical, with time deadlines and penalties (and yes money), if you do not hit the target date. The new project requires over 20 dedicated resources that are already 100 percent allocated to other projects or tasks. So what do you do?

a. Add a new project without adding resources, thereby delaying everything else, and ignoring the impacts?

b. Add a new project without adding resources, but, carefully plan the existing workloads and tasks for your team, thereby giving you the ability to inform your management of the likely impacts?

c. Add a new project, plan the required resources; add additional resources as a means to mitigate the likely impact to your other projects?

Too often I see project managers (PM) choosing option A, seriously. To add injury to insult, these same PM's create deadlines without sufficient milestones to measure progress or to gauge the amount of risk absorbed along the way.


How Does This Happen?


An ERP project will have scope creep. Add another module; increase the number of business processes to address; or increase the complexity of the task by training, not 500 people, but 5000 people. Maybe your company buys a new division from another company. You have until Christmas to migrate the other company’s ERP applications on to your company's production ERP system. Yes, all of these things have happened and continue to happen.

So what should the response be from Project Management? You may have no choice. It could be that you must complete these new tasks. However, without proper task planning (project plans, milestones and enough system/people test cycles) you are doomed to fail. How so? Missing deadlines is one common occurrence. If you go live, critical business processes might be unable to function at "Go Live", thereby costing your company much more than the monies saved by a one or two month delay. (The cost of failure is almost always more expensive than the cost of success.)

The proper response should be calculating the required resources needed and estimating the impact to your existing projects and tasks, assuming no increase to the available resources. Bear in mind that resources are not interchangeable. If you add a relatively inexperienced resource, that person will not replace the your senior resource you just committed to the new project. By completing this exercise, you can tell your management what the likely impacts are to existing projects, for both time lines and cost, as well as the non-monetary impacts such as employee frustration, long hours, mistakes, project and company morale.

In a coming chapter for our book we will discuss the basics of project planning and techniques on avoid the above problems, and how to inform management, even when they don’t want to listen or understand the pitfalls for poor planning.


18 July 2008

Who Does What? #3

This is the third and final discussion about who does what on an enterprise software implementation or upgrade project. After this post, I plan to focus on other topics we have been "batting about" in our conversations.

Business Process Analyst
Business Process Analysts (BPA) work with the BP Leads, process owners, and team members to facilitate the business process transformation work. BPA’s frequently come from the implementing organization because they know how the organization’s various business processes are performed under the legacy system(s). They also, in most cases, have the tribal knowledge regarding how an organization’s business process came into existence. This tribal knowledge helps the project and BPTT team determine the size of the business process gaps (current processes to desired processes), the company culture for initiating and accepting change and the underlying motivations and reasons for the current business practices.

Key qualities for BPAs:

  • Thorough knowledge of existing processes or the ability to find someone who has that knowledge
  • Respected by their peers, not a 2nd or 3rd string player
  • Desire to improve conditions and not necessarily married exclusively to the past practices
  • Able to see a larger picture, sometimes with ERP and process transformation some features or efficiencies are lost but overall the organization should gain efficiencies across the entire end-to-end process
Even more significant than the above key qualities, are the following questions:
  • Who will be your key business support people (note that business, not ERP, support is mentioned)? After you have gone live and the consultants have left (or you have redeployed your staff) who will support the end users and their respective departments?
  • Who will be responsible for the thinking about and planning regarding the future support team that will run the new business processes? Your BPAs should be considered as potential resources for these requirements. Select them carefully.
However, as noted with the organization’s BT Lead similar conditions apply to the BPA’s sent as members for the project team. They may not be the division or department’s top performers. This usually means that the BP Leads must motivate and mentor these individuals to ensure that all the work is completed. The gating factor for getting the best resources stems from the conflicts over the short-term “running the business now” vs. the longer-term consequences for “running the business later”. A more complete examination about this topic occurs later, when resource planning is discussed.

Training Materials Developer
Frequently an overlooked and unappreciated role, the Training Material Developer helps set the stage for how well an organization’s employees will accept the new business processes and systems. For most people the first time they see the system is during the user training sessions. Training should be appropriate for the audience, from both a difficulty level and a delivery method. Even with the best trainers, ineffective training materials limit how well the user community will learn the new business processes and systems.

The primary responsibilities for the Training Material Developer are:
  • Working with the Training Lead to use the selected delivery training channels for the target audience
  • Preparing the materials in advance of classes
  • Verifying the training materials meet the project standards, established by the Training Lead, Trainers, Business Transformation Lead and Business Process Analysts in advance of the training classes.
  • Revising the materials after the initial training sessions as needed.
NOTE: Many ERP implementation providers provide their own training materials (such as SAP Tutor or Oracle User Productivity Kit, for example) claiming the materials are “pre-built” and ready to use. Caveat emptor! Frequently these materials are merely role-based training materials, designed to illustrate the narrow focus within a user’s specific job functions. Training material developed in this manner does not provide the user community the necessary background for how the business processes work or the understanding necessary for when things go wrong or for when the initial business conditions change over time.

Sometimes combined with the Training Materials Developer or with the Business Process Analysts, the Trainer’s key task is to teach the user community how the new business processes and related systems work, with the goal of enabling them to perform their day-to-day tasks when the system goes live. Trainers should be familiar with the overall business processes and day-to-day tasks and how this relates to the ERP systems. Qualities to look for in a Trainer:
  • Have they delivered this training before? Do they understand the business processes and the ERP systems class participants will use?
  • Did they have similar or related roles in Industry or Government thus giving them the ability to relate to the class members?
  • Are they patient with class questions and able to answer when appropriate or table questions as needed?
  • How well do they communicate?
Trainer
Not all Business Process Analysts can teach. Depending on the staff’s capabilities and availability an organization’s wiser choice might be separate or contract trainers. When using trainers ensure they understand enough of the existing (As-Is) and thoroughly understand the future (To-Be) business processes so that they can impart this knowledge to class participants. Do not expect to be able to “parachute-in” trainers at the last moment and at the same time, have users receive quality relevant training; getting trainers on-board takes time.
NOTE: Typically a trainer is not responsible for teaching an organization’s users the fundamentals of their job tasks, such as Accounting Concepts for the Controller’s department or Inventory Record Accuracy considerations for the Warehouse staff. During the analysis of the training requirements and staff skill levels, the Business Process Lead and Training Lead should make this determination in advance and plan accordingly.

Training Coordinator
The Training Coordinator is responsible for all logistics for training. Sometimes this position is referred to as the BPTT team coordinator, in which case, this person handles all logistics related to business process transformation, communication, and training activities. Given the complexity on larger projects this role requires a highly organized person, flexible with frequent changes yet firm enough to be taken seriously by the other team members.

And although this position is usually staffed by a junior or less experienced person we cannot overstate the importance of this role. Without it, users will not be trained or, at best, trained poorly. And unless the project is small, do not expect the Business Process Analysts to do their own training schedules, as many classes should be scheduled in logical groups or sequences across business processes. Additionally, some class participants may need to take sessions across multiple business processes. The Training Coordinator can minimize the schedule conflicts and help give the training events the detailed attention that it deserves.

04 July 2008

Who Does What? - #2

On large implementation projects where the software “footprint” might include financials, supply chain, human resources, and distribution, there could be a sizable group charged with implementing Business Process Transformation and Training (BPTT) for a project. On smaller projects, you may have fewer people and even some roles combined, such as training material developer and trainer.

Who is part of the BPTT team?

  • Business Transformation Lead (aka Change Management Lead)
  • Business Process Lead
  • Training Lead
  • Communications Specialist
  • Business Process Specialist (aka Business Process Analyst)*
  • Training Material Developer (aka Instructional Designer)*
  • Trainer*
  • Training Co-ordinator*
Business Transformation Lead
Think of the Business Transformation (BT), or Change Management, Lead as you would a symphony conductor. It is his/her primary responsibility to keep all the different players on the BPTT team performing together with the appropriate timing and synchronization. In addition, the BT Lead lays out the methodology, milestones, and deliverables for the other BPTT team members.
On large ERP implementations, it is common to see two BT team leads - one that is a resource from the business (sometimes an HR employee who is tasked for the duration of the project) and another from a consulting organization. In a case such as this the BT leads jointly arrive at a methodology that fits the implementing organization’s environment, milestones that are consistent with the overall implementation plan, and deliverables that allow the organization to continue its business transformation after all the consultants have moved on to other projects. Smaller ERP implementations may have a single BT lead that could be “on loan” from the organization’s Human Resources department or a consultant from outside the organization.

The BT lead usually participates in all project update meetings, stakeholder committee meetings, the steering committee meetings, as well as leading meetings for the BPTT team. It is entirely possible for the BT lead to spend a third of his/her time in meetings alone, which means that the more organized and methodical this person is, the more easily all of his/her assigned tasks are completed. The challenge is finding someone who is at once personable, sensitive to an organization’s cultural and behavioral issues, organized, detail-oriented, verbally articulate, and quick thinking. In our experience we have observed BT leads who were personable, sensitive, and verbally articulate or personable, organized, and detail-oriented. It is a rare individual that comprises all of the cherished qualities of a BT lead.

One situation that occurs often enough to be noted is that organizations involved with business transformation using an ERP implementation or upgrade frequently send their “second or third string players” to the project team. In one business transformation project, the initial BT lead provided by the client organization was very senior and well connected throughout the various business units and departments. He was so highly thought of that he was pulled from the project team to take a new staff position in the executive offices. The next BT lead provided by the client was a talented woman from the IT department who was tempermentally unsuited to working in the fast paced project environment. Consequently, she returned to her previous position in IT and the team received another client BT lead. This individual has been with the organization for 18 months, working in one of the call centers. Thrilled to be out of the call center, this man was energetic and eager to participate in the project.

While the BPTT team members on this project welcomed him and his enthusiasm, there was also the recognition that this man had nothing in his work experience that would prepare him for the challenges he was about to face. As a result, the team spent 30% of its collective time mentoring this young man and teaching him about business transformation in organizations (much of what is in this book) so that he could be successful.

Business Process Lead
The Business Process (BP) Lead is the individual who works directly with business process owners and their teams to document current and future processes, improve processes, and align processes with software functionality. In a large ERP project that covers multiple functions of a business, it is possible to have a BP Lead for each core process the organization is considering for automation. In smaller projects, a BP Lead might have all of the financial core processes. Another could have all of the distribution processes. Some examples of organizational core processes are:

  • Record to report (financial)
  • Procure to pay (financial and distribution)
  • Order to cash (sales and financial)
  • Campaign to sale (customer relations management - CRM)
  • Sale to delivery (CRM and distribution)
  • Design to build (manufacturing)
  • Order to ship (distribution)
  • Hire to fire (human resources)
  • Customer contact to resolution (CRM)
Some of the best Business Process Leads were employed in other professions before working in the business process arena. It is the experience and understanding about business process that they learned in those prior environments that enables them to assist client organizations. For example, expert business process consultants in the financial area frequently have worked as staff accountants or controllers. Business process consultants in the CRM arena have functioned as sales or call center managers. In addition to understanding a particular functional area of business, Business Process Leads also know the strengths and weaknesses of the software that the client organization intends to use as part of its business transformation initiative. This knowledge enables them to help the client teams automate processes while minimizing customizations to the ERP software.

Training Lead
The Training Lead is responsible for several activities and tasks. The first task is working with the BT lead and Communications Specialist to discover who the end user community is, including finding out about:
  • how they are feeling about the coming changes in the business
  • how they approach training
  • what their learning styles are
  • how information is communicated through the organization
  • what their concerns and hopes are regarding the coming transformation in the business
In addition, the Training Lead’s responsibilities include:
  • identifying what the user community needs to learn and how they will best learn it
  • designing the curriculums for the various subgroups within the user community
  • ensuring that training logistics are handled
  • setting up the necessary “feedback loops” so that evaluation occurs at every step of the training development process
  • coordinating activities among the instructional designers, subject matter experts, and business process leads and specialists so that the training materials and delivery are as complete as possible for “go live.”
Communications Specialist
The Communications Specialist (CS) is charged with developing and executing a communication plan that describes the organization's reasons and goals for undertaking a business process transformation initiative. In many ways, the materials distributed by the CS are the first contact that employees have with the project. Further, the CS is responsible for producing project information updates and working with the PMO and BPTT Lead to keep the key messages about the organization's business process transformation on employees' "radar".

* coming in Who Does What - #3

27 June 2008

Who Does What? - #1

ERP implementation or upgrade projects, in many ways, have a life of their own. While the team members may report to accounting, sales, procurement, receiving, or a warehouse for their daily work, they become separate from those departments when they join the project team. Yet, it is extremely important that the project continues to be part of the overall organization and aligned with the corporate strategy. To ensure that this occurs, an umbrella organization is created - the PMO or project management organization. Effective PMO groups assist communication between the project and the organization as a whole. The PMO also helps the business process and training team by removing obstacles and facilitating communication among the client subject matter experts, the functional and technical consultants, and the BPTT team members. Who are the individuals that comprise the PMO?

  • Project Sponsor
  • Steering Committee
  • Program Manager
  • Workstream or Track Leads
  • Key Stakeholders

Project Sponsor

The Project Sponsor, typically a Senior Executive, provides the top management support required to see the ERP project to completion. Not only does he or she gets approval for the project scope, timeline and budget, but ultimately is held responsible for the project’s success. Necessary skills include the ability to navigate the politics across company departments, key external stakeholders, and fellow executives. The Project Sponsor’s activities do not amount to a full-time role, but depending on the size and complexity of the project, this role may consume 25% to 75% of his/her time.

The Project Sponsor also provides guidance to the project team on strategy, direction, and issue resolution at a more hands-on level than is possible for the Steering Committee (see below). In conjunction with the Project Manager, project sponsors may have responsibility for managing external suppliers and negotiating internal resources. The Project Sponsor is also the second point of escalation with respect to significant project issues. Although the Project Sponsor may have the authority to resolve these larger issues alone, these decisions are typically ratified with the Steering Committee before distribution to the project team.

Steering Committee

Every ERP project requires senior level sponsorship and buy-in across the company. Done properly, Steering Committees give senior management the ability to oversee the project progress and in doing so, help garner their support and increase their understanding. Steering Committees typically meet monthly and review project progress, provide overall project guidance, and provide positive, visible support to the organization for the project. They ensure the implementation is consistent with both the strategic and technical business goals and they resolve major business policy issues and internal conflicts that impact the project. The Steering Committee also helps manage project scope and approves all scope changes impacting funding, timing, and project risks. They set overall goals, milestones, and performance criteria and secure and maintain resource commitments for funding and personnel.

Project Manager

Just as every ship needs a Captain, every ERP project requires a part to full-time Project Manager to direct the day-to-day activities. Working under the guidance of the Project Sponsor, the specific responsibilities of the Project Manager include:
  • Developing and maintaining the project plan, including milestones, checkpoints, and deliverables
  • Establishing the project team and project resources
  • Monitoring and reporting the progress and status of project activities
  • Managing project resources to see that all tasks are assigned to an appropriate resource
  • Leading status meetings with the overall Project Team, Track Leads, Management, and the Steering Committee
  • Resolving implementation issues, escalating as necessary to Project Sponsor and Steering Committee

Track (Workstream) Lead

Most projects of any size require multiple levels of management. The Project Manager manages the overall day-to-day activities for the entire project, but in the example of larger projects impacting multiple functional areas or multiple business processes (sometimes called workstreams), Project Track (or Workstream) Leads manage the day-to-day progress of each specific area. Project Track Leads can do much of the heavy lifting, with up to 75% of their time allocated toward detailed project work as opposed to managing the track. However, the larger the project, the more management takes precedent over specific project work effort.

The Track Leads ensure that project activities within a track are worked through to completion and on schedule. The Track Leads share responsibility for coordinating project activities with other team members, meeting with other members of the project team as needed to resolve issues, completing deliverables, communicating status, and escalating issues as necessary to project management. Each Track Lead is also responsible for specific deliverables in his/her area of expertise.

Key Stakeholders

What about Key Stakeholders? Stakeholders are organizations or groups internal or external to your company who have a positive or negative interest in the outcome of your project and may influence the success or failure for the project. Internal Key Stakeholders for an ERP implementation or upgrade project include the respective department heads (Procurement, Logistics, Manufacturing, Finance, etc.) or if your company is organized around business processes instead of functional departments, the executives in charge of Procure to Pay, Record to Report, Order to Cash, Supply Chain Planning and so forth. External Key Stakeholders usually include your audit firm, customers, suppliers, or other groups not in direct employment by your firm.

Ultimately your Key Stakeholders decide whether or not the project is a success. For example, if you implement your project on time and on budget, but the key users of the project (which are usually represented by your key stakeholders) hate the results, face it, the project is a failure. They may even sabotage the new business processes and related ERP Systems in an attempt to return to the old way of doing things. If the Key Stakeholders are your customers they may go to your competitors instead of using the newly implemented ERP System. Given the potential to determine success or failure they should be involved early in the definition and approval of the project. And as projects do not progress in a linear fashion, the expectations of the stakeholders must be continuously be realigned with the project progress.

Critical Success Factors

What factors make or break a project? How can the above PMO members help or hinder the outcome?
Too many times PMO sidesteps its basic objective for getting obstacles out of the way for the team members actually doing the work. Instead you may find the following issues, mistakes, and hidden agendas:
  • How can this project help my career or bonus or recognition?
  • If the project is going badly, can I blame someone else?
  • Nevermind the facts, why can’t that task be done as planned?
  • Or no the project is not under-resourced, we planned it that way. You just have to work weekends and overtime to get it done.
  • We need a new ERP system and the IT (information technology) project team will drive new business processes
  • I’ve always used that third-party provider as my PMO advisors. So what is they do not understand the underlying technology, project risks or related business process areas?
  • Why communicate to our suppliers or employees or customers? They are not part of the project team.
  • I’ve heard about this new method for running projects. Lets do it on this project starting immediately.
Does any of the above sound familiar? Here are some project success factors common to all effective projects:
  • Project objectives aligned with the company’s business strategy.
  • Strong project leadership with well-defined project plans.
  • Project tasks, resourcing and timelines agreed across the Project Management Organization.
  • Project Sponsor, Steering Committee, Project Manager, and Track Leads, with:
    • Common goals and objectives across the project team, supported by the Steering Committee.
    • Having communication strategies in place for both within and outside the project with regular communication to sponsors and stakeholders.
    • Commitment by all project team members, PMO and Key Stakeholders to the project.
    • With the ability to quickly spot and resolve issues; having decision-making capability.
So how would you set out to organize your project to avoid these mistakes?

20 June 2008

Observations About ERP Implementations and Upgrades

Since my March 2008 post, several of us have begun work on a book about business process transformation and training. It’s exciting actually to start collecting in one, single place all the different observations and lessons we’ve experienced over the years. We have agreed on the topics we plan to cover. We have a schedule, and hope that we can keep it despite the reality that all of us have paying jobs for which we are responsible. Finally, it was also decided that I would share snippets of our thinking here. The notion is that some of you might have input, comments, or feedback about what we are saying.

Whose Idea Was It, Anyway?

The idea of a book about business process transformation and training (BPTT) is the outgrowth of numerous discussions with clients, conversations with peers, research, and over 60 years’ collective experience consulting with organizations that are working to achieve better business functions, and, ultimately, sustain a competitive advantage. Throughout all of these activities, we discovered that we had some observations that have become conventional wisdom at FMT Systems.

Observation 1: A process that is defined poorly with no “buy in” from the affected stakeholders cannot be automated.

Observation 2: Business process transformation is about better customer interactions, improved efficiency, and superior decision making. It is not about software.

Observation 3: Employees will not embrace or learn new software, especially an ERP system, without understanding the business reasons and rules, as well as the processes, which drive it.

Observation 4: Once started, business process improvement is an integral part of all organizational programs that seek to increase competency, i.e., Lean Initiatives, activity based management, Total Quality Management, Business Intelligence Competency Centers, and Learning Organization programs, to name just a few.

Observation 5: Too many ERP implementations fail to achieve their potential and, as a result, fail to recoup the monies invested. Although there are many reasons for this, the key failure for many ERP projects is lack of project communication among the participants and with its shareholders and customers.

Observation 6: Unless the CEO and CFO are openly and completely committed to the success of the project, it will, without a doubt, fail! This one came from a colleague who reminded me that I had told him this very thing when he was the CFO of a manufacturing company considering an ERP implementation.

Do these ring true for you? What have you observed during your organization’s ERP implementation or upgrade?

In the coming weeks, I will post additional snippets from our discussions on methodologies, tools, insights, and case studies, as we continue our work on the forthcoming book. Perhaps these posts will assist you in finding your way through the business process transformation and training maze associated with ERP upgrades and implementations. I hope you enjoy this sneak peek at our work in progress and look forward to your comments.

18 June 2008

When Companies Focus On Technology

The April Baseline magazine was sent to the office a while ago. I was finally able to carve some time to read it. For those of you who are unfamiliar with this magazine, it is published by Ziff Davis and its audience is senior IT professionals, i.e., managers, directors, IT/IS vice presidents, and CIO's. In its April issue, Baseline's cover story is about Symantec's ERP recovery.

This is an illuminating discussion about what can happen to an organization when it focuses on technology, rather than customers and business processes.

07 March 2008

Customer Happiness and Business Processes

Do your business processes help your customers do business with you?

Periodically I have been asked how FMT is able to compete with “the big guys.” After all, the company for whom I work is small. We have anywhere from 10 to 15 consultants on staff at any given time. The actual number depends upon the project requirements we have. So how does a firm like ours compete effectively?

I believe it is about focus, knowing what it is that we do better than anyone else. In our case, the focus is business process. While it is true that we work with our clients in a variety of ways – software consulting, education, training, metrics, business intelligence, and such; the focus of all those activities is: Process. It is all about how we help our clients get to a business process that makes doing business with them simpler and more satisfying for their customers.

Here’s an example of what I mean. Several years ago we worked with a small architecture firm in the Bay Area. They were competing for work that was also attractive to larger firms. Did this tiny firm win all of the bids they submitted? No, but they won about 35% of them. They were successful by having business processes that were focused on making their clients happy. One of the processes that their clients liked best was the ability to log in to a secure area on the firm’s Web site and access all the relevant documentation for a particular project, including specifications, renderings, building plans, and such.

Today such access might be considered mundane. In 1996, it was a client exciter! Suddenly it was no longer, “Did the delivery service driver get caught in bridge traffic? Did she have an accident? How long will we need to wait to see changes?” In addition to showing its clientele how customer focused the firm was, this process change affected the bottom line. It eliminated 90% of the firm’s delivery service charges and printing costs. Since the business process also shortened the cycle time for approval of revisions, billing went out more quickly reducing receivables aging and improving cash flow. Last but not least, the firm generated more business with their client base because they were perceived as “easy to do business with!”

Now we (architects and business process consultants) could have approached redesigning their business process from the viewpoint of reducing costs and maximizing revenue, but I doubt that whatever was developed would have made their clients as happy as this customer focused redesign did.

One of my main objections to ERP implementations and upgrades, as they are currently handled, is that they are viewed as technical exercises only. When they should be opportunities to improve not just an organization’s business processes but also refine those processes such that they increase the organization’s customers’ ability to transact business easily. Too often an organization’s employees concentrate on the mechanics of simply trying to automate a business process within the constraints of software (chosen by executives who will rarely use it) that the opportunity to improve the business process from the perspective of a “user experience” that is satisfying, and not frustrating, is missed.

Further, using ERP software to implement best practices begs several questions. Whose best practice? How long ago was it considered a best practice? Is there a recent innovation in best practice that is not included in the ERP software? From the viewpoint of customers who transact business with us, is this best practice for our organization? Expecting ERP software to improve an organization’s business processes can be fraught with disappointment. Better to redesign with customers’ ease and satisfaction in mind and address software later. The good news is that with the rise of SAAS (software as a service), automating business processes that incorporate the customer’s view may get easier.

I'd like to see what others think about this topic. Click the comment link below and let me know what you think.