Management Consulting | Jason Palmer, CPA, CITP

The Security Value Context – Data vs. Information

August 16, 2012 By Jason Palmer Leave a Comment

All Information is comprised of Data but not all Data leads to useful Information.

Data should be protected where possible but it is Information that needs to be actively secured.

The Security Value Context is the degree to which Data or Information needs to be protected and secured based entirely on the context of how it is organized and how it will be used.

Let me explain: If I have a Tax Preparation Business with thousands of individual client returns, considered Data, no one specific return is particularly interesting (unless perhaps the return belongs to a Public figure, then it becomes Information.) In fact, if I published one random Tax Return, (say Mitt En), on a Billboard in Times Square (without the Social Security Number), chances are no one would give it a second glance. Even if someone knew Mitt En, there is little practical value to the Data presented on the Tax Return. Big deal, the world now knows how much “Mitt” took home last year. The point being made here is that this Tax Return is just random Data. Unless someone is specifically interested in Mitt, and most people are not interested in Mitt, there is extremely limited security value risk to Mitt in the public exposure of his Tax Return. In short, the scope of the Context is singularly “Mitt” himself. No one else really cares.

(For the moment, I am excluding the possibility of Identity Theft from this discussion.)

On the other hand, if this is the Tax Return of Mitt Romney instead of our average individual Mitt En, what a moment ago was random unimportant Data now becomes specifically useful Information. The Tax Return will most likely list all of the Charitable Donations that Mitt Romney has made. This Information will imply the causes that he supports which in turn may suggest the types of Policies he will try to legislate based on his beliefs and values. This has a very high security value risk and therefore needs to be actively secured. The scope of the Context is huge. The majority of the voting population of the United States cares.

If I take the thousands of individual client returns and start to analyze and segregate them based on factors like income, mortgage interest paid, charitable donations, type of employment, dependents, or any other element, I have taken the raw disorganized Data and turned it in to incredibly valuable Information.

Used in a good way, the Internal Revenue Service aggregates the Data from Filed Tax Returns in just this manner to present anonymous profile statistics about the American Tax Payer. This provides valuable information that Congress can use to manage Tax Policy. Since the Data is presented in anonymous, aggregate format, there is a very low security value risk to any one individual return.

Used in a bad way, an unscrupulous person could use the identifiable Data that created this incredibly useful Information against specific groups of individuals for nefarious purposes. For example, groups of individuals that have high mortgage interest deductions might become the target of predatory refinancing lenders. Since each person can be identified, there is a very high security value risk.

It is impossible to know exactly how raw “Data” will be organized or its’ eventual value in producing Information which is why it is important to take appropriate action to protect it. For example, we manage user access with Password protected Software Applications and we encrypt the files to keep the Data as secure as practicable away from unauthorized access.

Conversely, we know exactly how “Data” can instantly become valuable “Information” which is why we go to such great lengths to actively secure it in its final form. We know that a Tax Return contains a Social Security Number, Birth Date, and the full legal name and address of an individual. In the wrong hands, like that of an Identity thief, the information on a Tax Return contains everything necessary to steal the Taxpayers identity and create financial chaos.

Actively securing access to valuable Information, like a Tax Return, requires more than a Password. It requires a policy that explicitly defines how the Information will be stored or transmitted and who will have access to it.

The simplest analogy to the difference in managing “Data” security vs. “Information” security is to think of “Data” as a Credit Card and “Information” as Cash.

With a Credit Card, if a fraudulent transaction is discovered, it can be reversed, the Card cancelled and your perfect credit score remains intact. Data stored on your computer works pretty much the same way: If a file becomes corrupted or damaged, that one data element can usually be isolated or fixed with minimal risk to the remainder of the data. It is one random element among many.

With Cash, if you lose it or it is stolen, it is completely gone with zero recourse. With valuable Information, like a Tax Return in the wrong hands, you can never get it back. The person’s identity may be stolen along with the creation of a financial mess that may take months to clean up.

Determining the Security Value Context of Data vs. Information requires an understanding of how each will be stored, accessed, and presented.

One person’s Data is another person’s Information.

Business Process Consulting – The Never Ending Development Event Horizon

August 10, 2012 By Jason Palmer Leave a Comment

“Life is what happens while you are making other plans.” In the same manner, Projects and System Implementations occur in phases that are subject to available staff resources, the seasonal workload, and budgetary constraints. Any of these issues can affect the event timeline to completion. The more granular the tasks and milestones, the lesser the impact of any one issue. It is expected that some delay will be introduced because of the number of people involved or because of unforeseen circumstances.

The Never Ending Development Event Horizon refers to what I call the Breeder Reactor Effect: As Staff start to use the System, new efficiencies in processes will occur. The System will introduce a new set of resources for the Staff to use in completely new processes. This will lead to the Evolutionary effect on the Business Process culminating in the realization of “I could never do that before” coupled with “I wonder if we can to this, too?”

As Staff start to discover and utilize the new capabilities, Staff will come up with brand new ways to continue to expand and extend the System. Each of these will create a new Project Event. Hence, the System is never truly finished as there will be constant improvements and enhancements.

For example, until the Smartphone was invented, it was not common to be able to send email unless you were at a computer physically attached to the Internet. So the ability to send email using the cellular data network was the planned feature of the Smartphone ecosystem. (Think Blackberry.) Then someone noticed that the Smartphone had a built in GPS (Global Positioning System) and developed a mapping and “directions” application. A completely new use that was never possible before the introduction of the GPS capability in the phone. One need only look at the Google Android and Apple IOS iPhone Smartphone operating systems to see that hundreds of thousands of new uses and applications have been developed proving my point of the “Never Ending Development Event Horizon.”

Projects and System Implementations take on an organic nature and continue to grow and evolve over time. If properly managed, they are constantly refined and enhanced so they never truly end their development life-cycle.

Business Process Consulting – Utilizing People Resources Effectively

August 9, 2012 By Jason Palmer Leave a Comment

Nothing is more of a mystery to me than the relationship between Management and Staff. It absolutely amazes me how Management and Staff will verbalize their criticism of each other among themselves but not to each other – at least not intentionally. The most interesting part is the view that either Management or Staff are incompetent, cannot be trained, and will not change. Building on a prior theme, I pose the question: “Is this perception or reality?”

My response to this dysfunctional environment, which I encounter more often than not, is to eliminate the Managerial preconceived notions of Staff capabilities by demonstrating their inherent abilities and value to the Project.

Fact: Everyone is doing their job at some level or they would be fired.

Fact: These are the Staff resources available for this project.

Management’s impression of Staff should not automatically be my impression of Staff.

When questioned about my “Get it done” attitude, I like to use this example: “I am behind enemy lines with this crew. Safety is twenty miles away through hostile territory. This is what I have to work with.” I will improvise adapt, and overcome – just like the US Marines.

Everybody has some level of talent, skill, and creativity. Everyone likes to feel like they are part of the process and that their opinion and efforts are valued. This is where Management mostly fails. It is what I call “Managerial Insanity” – working with Staff the same way, day in and day out, and expecting a different result. Management rarely wants input from Staff and certainly does not want to hear from Staff about how Management could do their job better.

As the Consultant, the key is to engage the Staff as part of the process which then motivates them in to action. The easiest way to get Staff involved and excited is to ask, “What is the problem (we are trying to solve) and how would you do it differently?” Even if the Staff are not creative thinkers, recognizing each person’s capabilities and using them within the limit of their abilities is perfectly fine – and gets the job done.

My Dad and I used to have deep discussions about people’s abilities. He always said that if the Student did not learn or could not perform the task, it was the Teacher’s fault. (You can substitute Staff for Student and Management for Teacher.) I always said, that there is a reason the Peter Principle exists, “Everyone rises to his level of incompetency.” Not everyone is infinitely capable. Understanding this fine line between the likelihood of being able to effect immediate change in the level of Staff capabilities (not very practical) vs. utilizing the current abilities of Staff to their maximum potential is the entire key to success and what I specifically try to do.

Unlike Management, the Consultant should be able to take inventory of the available skill sets of Staff and use them appropriately thereby maximizing all of the resources available to complete the Project.

With rare exception, every Staff person has something to contribute.

Recognizing that all people have value is critical to utilizing all Managerial and Staff resources effectively.

Business Process Consulting – Reviewing the Inputs and Outputs

August 8, 2012 By Jason Palmer Leave a Comment

When performing a Business Process Review, think of the Software System as a Black Box. There are usually a number of similar software products from multiple vendors available to resolve most operational problems. The specific vendor is not necessarily a factor as most offer comparable levels of service and support and are competitively priced.

The most important issue to consider is the usability of the system.

Considerations regarding the User Interface include: Are the screens in a modern Graphical form or are they more “Green Screen” Text Entry like? Are keyboard shortcuts available or must everything be done with the mouse? Are there Macros available for repetitive keystroke sequences? Will the software pre-fill fields with default information based on data entered in preceding fields? (If I enter in a Utility Bill, will the system pre-fill the remainder of the form by recalling the prior months’ transaction?) How many mouse clicks are required to perform various tasks? If frequent lookups are performed, what fields support lookup and which fields are indexed? Does the system support lookup by both Customer Name and Customer Number? Can you do a lookup/search in any field?

The ability to navigate the data entry screens quickly and efficiently is absolutely critical to productivity. Every time the user has to take his or her hands off the keyboard to reach for the mouse, time is lost. There needs to be a proper use of real estate on the screen balancing the number of fields presented vs. layout and readability. Confusing and crowded screens lead to data entry errors.

When searching for data, does the program use a “Word Wheel” so that as letters are entered, the lookup field starts to populate with possible choices? (This is similar to auto-fill when typing in to a Google Search box. As you type, Google makes suggestions.)

The most important aspect of Search: Does the software program organize the information in a manner similar to the process that it is designed to automate or replace? Many Companies organize records by Customer Account Name. Some software systems only support lookup on a Customer Number. If the software does not support searching by Customer Name, then it is not the right software package for our process. We want a software system that adapts to our way of data organization and not the other way around. Even if we need to create Customer Numbers for other purposes, the system should work the way we work.

It is easy to define the Inputs and Outputs.

We need only look at our Source Documents – Phone Orders, Order Forms, Bills, Payments, Customer Service Registration Information, Sales Leads, etc. to determine what it is our new software system needs to accommodate for the Inputs. Then, for the Outputs, we look at every Report and Document created or printed – Financial Reports, Checks, Packing Lists, Statements, Invoices, etc. (and any manual processes to get our Report Data.) A Review of the Operational Analysis will tell us what “wish list” Data and Reports are missing.

The key to a successful software selection and implementation is for each Department to define their ideal set of inputs (source data) and outputs (reports) and to make sure they are accounted for in the new system.

Since the desired Outputs represent a definite, tangible milestone for sign-off and acceptance, a positive outcome is virtually guaranteed.

Business Process Consulting – Mainstreaming Exceptions

August 7, 2012 By Jason Palmer Leave a Comment

Frequently when performing a Business Process Review I see that I am documenting multiple, recurring exceptions. In speaking with the employees I am told, “This is an exception because our present system does not allow me to do this process without…” and then they proceed to tell me all of the additional steps required to accomplish the task.

If everything is an exception, it becomes the norm and needs to be included in the new system.

Exceptions are really just shortcomings in current processes that do not allow for the required procedure. In some cases, exceptions are the result of not being aware of current system capabilities. Or, there may be new enhancements and features included in a recent system update that have not been communicated to the Staff.

Another exception is the frequent creation of Data Exports and Spreadsheets due to failures on the Reporting capabilities of the current system.

Data exports should only be created if they pass data to another system for additional processing. For example: After processing orders, a Data Export of Shipping Address information might be passed directly to a UPS/FedEx manifest system to create shipping labels or way-bills.

Spreadsheets should only be created for unique customized analysis events like litigation support or specialized one-time financial reports. If system data is frequently exported to a Spreadsheet for further analysis or customized reporting, those reports should become standard reports in the new system.

Exporting data either for transfer to another software program or to a Spreadsheet has the potential to destabilize the integrity of the data. While the data is in the system, it is 100% standardized. Formulas are set and calculations have been tested for accuracy. Once the data leaves the system and is placed in a Spreadsheet, Formula and Calculation errors can creep in. A row or column of data can be left out of one of the formulas or can be accidentally deleted entirely throwing off the accuracy of the result. (Where possible, rather than exporting data out and importing data in to another system, a real-time link should be created between the two systems so that data integrity is properly maintained.)

The most detrimental aspects of exporting data are that it localizes the analysis and reporting process to one individual or team and it may be difficult to reproduce the output/result with certainty by another individual or team due to lack of proper documentation. Once the data leaves the original system, it immediately becomes stale and out-of-date. Any change to the original data will not be reflected in the analysis and reporting process unless a new data export is performed.

When reviewing the Business Process, watch for exceptions, document the shortcomings of the existing system which require the work-around reporting, and make sure they are provided for in the new system.

To put the concept of an exception in context: We may think of something that has a “One in a Million Chance of Happening” as being a rare exception. However, something that has a one in a million chance of happening happens twenty times day at McDonald’s based on the volume of customers served. Twenty of something happening means that it can be identified and accounted for in the design and implementation of the new system.

The goal of good system design is to standardize any repetitive tasks so that predictable, consistent results can be obtained every time.

Business Process Consulting – Managing Expectations and Defining Goals

August 6, 2012 By Jason Palmer 1 Comment

Managing expectations and defining the goals of a Business Process Review with the intention of implementing a new system implementation is easy if you can separate perception from reality. Although Management and Staff must each give their own impressions and expectations of the current system as a starting point, this must be translated to tangible deliverables and goals.

Many times someone will vent, “The system we use is absolutely terrible”, (perception), when on closer questioning, (reality) “I cannot get one type of report”, is the specific issue that caused the blanket statement. It is easy for people to make gross generalizations. It requires digging and careful questioning to get to the root cause of the generalization and determine the specific issues – good or bad.

The mission is to line up impressions and issues in the current system against expectations and actual deliverables in the new system.

The easiest way to manage the implied expectations and define the Goals of the new system is to define the outputs, for example in these systems, the goals are fairly clear:

Phone System – Can I answer and make telephone call?
Accounting System – Can I produce a full set of Financial Statements
Inventory Control – Do I have real-time stock visibility?
Point of Sale – Do all items scan with minimal key code entry for bar code errors?

An underlying requirement is that the Project must be fully funded. Running out of money during an implementation or going over budget is a sure fire way to not meet Management’s expectations (on-time, on-budget implementation) and goals (a working system that meets the specification.) During the Operational Analysis, the issues raised need to be prioritized and evaluated. In some cases, the cost of a “perfect system” may be too high and certain solutions may be excluded from the new system.

The expectation and goal of any new system is that Management and Staff will be able to obtain the desired reporting from the data entered. In short, if the new system has a space for all of the different types of inputs (i.e. Order Entry, Bills, Customer Service Records, Cash Receipts, etc.) and can generate all of the desired outputs and reporting, (i.e. Invoices, Financial Statements, Sales Reports, Checks, etc.) then usually both the expectations and goals will have been met.

By meeting with each Department and making sure that their current and desired reporting requirements are met in the new system, you will have met their expectations (hope) and goals (actual deliverable.)

The failure of many system implementations is the extreme disconnect between what Management and Staff perceived the New System could do vs. what the Vendor actually disclosed that it would do.

In a real world example, I was brought in as a System Implementation Consultant. Contracts had been signed and significant payments were made to the Software Vendor prior to my arrival. In reviewing Management’s expectations and specifications, I determined that the new software could not meet three of the critical requirements that the Vendor had given the perception of being able to do in the proposal. In more direct terms: The Vendor flat out lied about the capabilities of the Software.

This was not fully acknowledged by the Vendor until the “checks had been cashed” and the only recourse for the client was to move forward or commences legal action. Not only did expectations have to be reset to a lower bar, but to work-around the issues, required tens of thousands of dollars of custom programming. (This caused an additional problem in that any future upgrades to the main system would require significant additional expense to upgrade the custom programming. The client could never install any new release without paying thousands in fees.)

Needless to say, this project was doomed from the start and only a marginal improvement over the existing previously, failed system implementation.

Make sure that the perceived capabilities of any new system line up with the realities of its’ actual capabilities.

If you properly align the expectation with the goal and reality with perception, the System Implementation Project will succeed.

Business Process Consulting – Technology Requirements Planning

August 5, 2012 By Jason Palmer Leave a Comment

One of the most important aspects of any System Implementation is the configuration of the computer hardware required to properly run the software.

The Software Vendor will provide minimum specifications to run the System but will usually offer little guidance on the optimal specifications. For example: The Vendor may state that the software runs on Microsoft SQL (or similar database), Windows Server, and a current Microsoft desktop operating system. As long as your systems are able to run those Microsoft products, the Vendors’ software will run properly. The Vendor will prefer that you look to Information Technology Professionals to determine the best configuration.

The Vendor shirking their responsibility to help you properly determine the best hardware configuration for their Software is a potential for failure of adoption and long term use of the new system. If the hardware is underpowered and that causes performance and usability issues, productivity will suffer.

There is a significant difference between “minimum” and “optimal.” You can watch a movie on a Smartphone (minimum), a Tablet (better), or a 60” Flat Panel TV (optimal.) The experience is completely different.

It is critical that the Software Vendor provide real world computer configuration recommendations based on the number of transactions expected for your Organization instead of just “minimum requirements.” Even selecting the right infrastructure software can have a big impact on the equipment portion of the budget. For example, Microsoft SQL comes in a variety of flavors: Express, Workgroup, Standard, and Enterprise. If your company is doing just a few hundred or even a few thousand transactions a month, the free version of SQL Express may be more than sufficient and requires significantly less computer horsepower than if you are processing tens of thousands of transactions per month. If the volume of activity requires one of the higher end versions of Microsoft SQL, that could add thousands of dollars of computer equipment, “infrastructure” expense.

The hardware vendor will only submit a proposal based on the minimum requirements provided by the Software Vendor. Understand that hardware vendors like to sell built in obsolescence to insure faster computer replacement cycles. There is no incentive for the hardware vendor to do otherwise since they only make money by selling more equipment, more often.

The Software Vendor may purposely specify minimal hardware requirements to keep the overall budget as low as possible or so that more of the budget is available to spend on Software, Options, or additional consulting.

This is where a Business Process/Systems Implementation Consultant plays an important role. Unlike the software and hardware vendors which take a myopic view of “just enough equipment to make the sale,” the Consultant will have the long term “Big IT Picture.” This includes the planned growth rate of the System and the desired lifespan of the computer equipment. The Consultant will insure that any budget considerations are not at the expense of long term performance.

In summary, when considering the Technology Requirements for the System, it is critical that all parties be at the table: Software Vendor, Hardware Vendor, Internal or External IT Staff that will be responsible for the on-going maintenance of the System, with the Business Process/Systems Implementation Consultant as the moderator of the Conversation.

Remember, the Business Process/Systems Implementation Consultant is the only truly independent person whose sole mission is to represent the best interests of you, the Client.

Business Process Consulting – Managing the Vendor

August 4, 2012 By Jason Palmer Leave a Comment

As the voice of the project, the Business Process Consultant should stand between the Vendor and Client. Vendors usually have a very specific way they like to manage their clients which is like lemmings that will blindly follow their lead.

Put simply: The Business Process Consultant should manage the Vendor instead of the Vendor managing the client.

The Vendors’ time line usually assumes that the Client does not have the in-house expertise to manage an implementation nor any single point of contact for answers. This is where the Business Process Consultant becomes the Clients’ secret weapon.

In an average Systems Implementation Proposal it states that the Vendors’ “Project Management Team” and “Consultants” will spend some number of hours ironing out the details of the “actual” work to be done to implement the system. Since the Vendor Proposal was written by the Sales Department, days of time are added so that the Vendor can “gain an understanding of the Client’s needs” and rack up as many extra hours as possible.

If the Business Process Review has been done properly, the Business Process Consultant short-circuits this incredible waste of time by the Vendor. We do not need the Vendor to gain an understanding of our environment nor do we need them perform yet another review of our operations. We need the Vendor to immediately get to work and provide best practice suggestions AFTER reviewing our findings.

Here is a real world example of the tangible benefit of Managing the Vendor: I was the Business Process and Systems Implementation Consultant to a large non-profit that was changing over its’ Financial Reporting System which included the General Ledger, Accounts Receivable and Accounts Payable, as well as a number of other modules. I had spent a significant amount of time performing the Business Process Review during which I was responsible for the creation of the new Chart of Accounts for the General Ledger and documenting the dozens of required reports. (Note: Although my focus is as a Technology Consultant, I am also licensed Certified Public Accountant in the State of New York. My ability to reorganize the Chart of Accounts was just one of the many skills I brought to this Project.)

On the first day of work with the selected Vendor, the Vendor Consultant opened the meeting by stating it would take a number of weeks to review our current system and gain an understanding our reporting needs. The Vendor Consultant stated he might start programming the new General Ledger in about a month and that within three months it might be ready for testing.

Imagine the expression on the face of the Vendor Consultant when I handed him a fully vetted Chart of Accounts for the General Ledger, the Accounts Receivable, the Accounts Payable, a full list ready for import of all customers (technically donors and pledges) and another list ready for import of suppliers and the layouts for all of the required reports. After some preliminary discussions regarding best practices and required setup information for the Software, the Consultant started installation and configuration that afternoon.

This saved thousands of dollars in unnecessary duplication of Vendor consulting time with work that had already been done as part of the Business Process Review. More notable, it enabled me to put up a Full General Ledger with Accounts Receivable and Accounts Payable in 45 Days. Yes, you read that correctly: From “Day One” to the printing of the first check in the NEW system in only 45 days – instead of the six months to a year that it usually takes “Vendor Managed” General Ledger Projects to complete.

As demonstrated, the use of a Business Process Consultant to manage the System Implementation and the Vendor will lead to significant cost savings and a shorter delivery time.

Business Process Consulting – Implementation Success Starts at the Top

August 3, 2012 By Jason Palmer Leave a Comment

For a Business Process Review and System Implementation to be successful, Senior Management must support the Project.

Whoever is given the responsibility must have commensurate authority – specifically, the final say on implementation details. The Consultant must have full access to every department and employee. When dealing with Vendors, the Consultant needs to be the only voice of Senior Management and have complete control of every interaction with the Vendor – short of signing a contract or issuing payment.

It is critical that Staff understand that Senior Management has mandated that the Consultant has been empowered to effect change. This will assist with Employees becoming part of the solution instead of part of the problem.

We have all heard the expression, “Too many cooks spoil the broth.” This is especially true in when managing a new System Implementation Project. The Consultant must be a Benevolent Dictator to assure success. The Consultant will interview all stakeholders, objectively listen, and document concerns. In a perfect world, the new system will address the needs of everyone. Unfortunately, no System is ever perfectly designed. To that end, it is the Consultant, who must be allowed to determine where compromises will be made in the final design and implementation since he or she is held singly responsible for the project’s success or failure. Remember: Responsibility with Commensurate Authority.

I can tell you from firsthand experience that Implementation Projects immediately falter and are doomed to fail when Senior Management waivers on the delegation of control, starts to second guess decisions, or dictates ill-advised changes. It is the Consultant, the keeper of all project knowledge, who is the most qualified to “Steer the Ship.” For a Senior Manager, even if he is the President of the Company to step in and force a change without all of the facts and background virtually guarantees failure or at least significant budget overruns.

Here is a real world example: I was the Project Manager operating with full authority for the implementation of a new Donor Management System for a large non-profit. Over the course of decades, the original system had been converted from a paper based one and at least two prior computer based accounting/donor management systems. Although the statement of each account balance total was absolutely correct, due to prior conversion issues, manual journal entries and adjustments had been made to the accounts to get all of the funds to balance properly. When attempting to import the original transaction detail items to recreate and obtain matching statement balances in the new system, it became impossible because of the prior manual adjustments – which were not reflected in the individual transactions being imported.

The planned solution was to generate a final statement from the old system and start fresh with verified opening account balance totals in the new system and send clients two statements showing the overlap. The CEO stated that it was “unacceptable” to send clients two statements and that “no matter what” we would have to import transaction detail from the old system and get the numbers to balance in the new system. The CEO mandate was that the client should continue to receive one statement with all transaction detail since inception of the account. We attempted this process for weeks. Every time an adjustment was made in the new system to try to emulate the original manual entries in the old system, we would balance one account and throw off another. A month passed then two, then three. Instead of clients receiving two statements, clients received no statements or for the largest clients who complained the loudest, statements were typed up by hand.

Fortunately, the CEO eventually relented and the Project was put back on track with the original solution of delivering a final statement from the original system with the historical transaction detail and a statement with a matching opening balance from the new system.

To my point above, tens of thousands of dollars were wasted on unnecessary programming and consulting time to try to resolve a problem caused by entirely by the CEO’s meddling in the solution. The CEO was unaware of the conversion problem, which had been resolved in the original solution, and made a decision based on incomplete information.

Senior Management must have full faith and confidence in the experience of the Consultant hired and the Implementation Team to make the best choices for the Project to be a Success.

Remember, it all starts at the top.

Business Process Consulting – The Details are in the Documentation

August 2, 2012 By Jason Palmer Leave a Comment

Many businesses have never documented their procedures and subsequently have no institutional memory to determine if a procedure has changed.

This is not to say that without explicit documentation of procedures that one cannot run a successful business. The problem is that the documentation may only exist with the particular person responsible for the job function. Or, perhaps Management runs on instinct. This can lead to potential critical points of failure with too many Staff rising to “Key Employee Status” – a person so critical that were he or she to disappear, the viability of the Business might be at serious risk. With documented procedures, others can step in as temporary replacements in times of crisis because they have the the institutional memory of the company to follow as a guide.

Part of a Business Process Review is to create objective documentation of the current procedures. As companies grow, without documented procedures and periodic review, changes can occur that were never intended or approved by Senior Management.

For example, let’s look at how payments to customer accounts are received and applied in a company that receives paper checks in the mail: One person opens the mail and makes a list of each check received with the check number, customer name, and amount. A second person applies the payment to the appropriate customer account. A third person might write up the checks for the Bank deposit. This type of Financial Control virtually guarantees that unless the three individuals are intentionally colluding to defraud the company, the separation of function acts as a check and balance to help keep the Staff honest.

What if due to a reduction in Staff in the Accounting Department, one person had the complete responsibility for opening the mail, applying the payment, and making the Bank deposit? Since most employees are honest, probably nothing. (However, the fact is that the separation of function and financial controls exist specifically to try to prevent the temptation to commit fraud.) With a properly documented procedure for reference, during a periodic Business Process Review, this change would immediately become apparent to Management.

While documenting the current procedures, a Business Process Consultant might uncover something as simple as a Field employee not having the proper tools to do his or her job.

I recently call the AAA auto club to change a flat tire. The contracted garage supplied the Mechanic a tire iron and a jack but no Flashlight. My car was in a dimly lit parking facility and that made placement of the jack under the car difficult because it was dark

For want of a Flashlight, the company put the employee at greater risk of injury and created a loss of productivity. He could not see the exact spot to place the jack so the job proceeded more slowly. (That was until I pulled out my trusty Ultra High Powered Zillion Candle Power Maglite Flashlight and lit up the area like Times Square. As a former Boy Scout, I am always “Prepared.”)

When I called the owner of the Garage to bring this to his attention, he was surprised and puzzled. The Garage owner said he would look in to the matter and call me back – and he did. It seems the new Dispatch Manager had determined the equipment list based on his own experience. He had only worked during daylight hours in the Suburbs where the cars are usually parked outside in a driveway or on the street. The new Dispatch Manager was not familiar with NYC where many cars are kept indoors inside poorly lit Parking Facilities. The Garage owner thanked me for my call and said he would remedy the problem immediately.

The above real life situation was a “freebie” for the Garage owner but nonetheless, I uncover the same types of issues at my “paid” clients too.

Baseline reference documentation creates “institutional memory” of approved procedures.

Senior Management can use the documentation created during a periodic Business Process Review to determine if any changes observed in current procedures should be approved and added to the institutional memory or returned to the original procedure.

Without proper documentation as a reference point, there is no way to determine if deviations from approved procedures have occurred. That can put the company at greater risk or reduce productivity and therefore impact the bottom line.

Remember, “No job is finished until the documentation is done.”