Process Knowledge = Efficiency

Not understanding your company’s business processes has to be considered a cardinal sin, especially during this economic recession. For the past five years the majority of companies have either downsized their workforce or issued hiring freezes to cope with the economic conditions. Because of this downturn, sales forecasts and revenue expectations at most companies are tempered, however the number of operational improvement and cost saving projects seem to be increasing in an effort to offset the decrease in sales. Essentially, senior management is demanding that Operation’s increase their workload without increasing their workforce. So how does understanding your company’s business processes help solve the problem? 

Historically, the people who cared most about what affect department A’s operations had on department B’s were project managers. The project manager would scope out dependencies and document task sequences. Working with project managers offloaded the need to understand any task that fell outside your immediate circle of responsibility. With good project managers this solution works well. The problem arises when the number of projects is greater than the number of project managers. By having management demand a multitude of cost saving projects you’ve increased the demand for project managers without increasing the supply. It’s important to note that a project manager, as described above, isn’t necessarily an employee assigned that job title but instead the person who spearheads the project.

With limited or no project management help it now becomes imperative for employees to understand, at least at a high level, your business process flow. That’s not to say they need to fill the role of a project manager but what it does mean is they need to understand how they get their inputs and who uses their outputs. These inputs and outputs are not only physical, but include things like accounting information, database code, shipping terms, and lead times. As employees begin to understand these processes and how their job affects those downstream, a host of benefits arise. These benefits might include; cross department collaboration, decrease in project implementation time, improved time management and multitasking, and increased visibility and awareness. 

Take, for example, a buyer who’s been told he needs to reduce the costs of submitting RFP’s to suppliers. This buyer might turn to IT for web option to facilitate this process decreasing emails and phone calls effectively reducing the cost of submitting the RFP. If the buyer understands the IT development process, he’ll know upfront the inputs he’ll need to provide include; business requirement documents, supplier data to be used in development, security requirements, and webpage design ideas. If the buyer understands the process he’ll also know that somewhere in the middle of the project IT is going to provide a beta version of the solution as an output that he’ll need to critique, test, evaluate and summarize as an input back to IT so they can finish the process.

By knowing the process the buyer reduces development time, he understands he can work on other projects until IT has the beta version ready, and he knows when that version is ready he needs to allocate some of his time to testing. Essentially, because he knows the process he becomes more efficient. That efficiency is the key to weathering the storm during this recession. With more efficient employees; your reliance on project management greatly decreases, it’s easier to accept the workload that comes with cost savings projects, and hiring freezes don’t hurt as much. In the end, you see why not understanding your company’s business processes has to be considered a cardinal sin, especially during this economic recession… because it severely limits your overall efficiency.

The Challenge of Completing/Fixing Someone Elses Work

Over the past nine months my major goal at work has been to manage our upgrade from 11.5.10.2 to 12.1. My time and attention is primarily focused on this upgrade, however, since this project includes so many other departments and users (DBA's and our Hardware team specifically) I find that I have spans of three to four days of downtime waiting for someone else to finish their part of the migration. During these waiting days I've gone through some of our older project plans to verify that things are functioning as they were originally outlined and I've found quite a few projects that got partway completed and then abandoned. After reviewing the projects and trying to resurrect them, I've decided that trying to complete someone else's work is infuriating.

Lets take our implementation of Daily Business Intelligence as an example. Two years ago a co-worker began to roll out daily business intelligence to our purchasing and payables departments. Shortly after he began this project he decided to take another job outside the company. Since he left not a soul has touched the DBI project he began.

I became aware of this project a couple months ago and so during my downtime with R12 I decided to see what needed to happen to finish the DBI implementation and rollout. Without going into too many details, here is what I've learned (actually the better term would be re-learned) from trying to resurrect and complete this project.

1. Documentation is absolutely critical
2. Open communication is a 'must'
3. Projects need more than one team member
4. Oracle documentation is weak (and I'm probably understating that point)

A quick explanation of each point above

1. Documentation: My co-worker outlined the project and began working on it, however he did not keep track of what steps he completed nor how the overall project changed during his discovery and initial rollout. Because he omitted completed steps and project changes I had to essentially walk through oracle documentation step by step in conjunction with a DBA to see how many steps he completed before I was able to get an idea of what needed to be done to finish the implementation. I also had to meet with the departmentes involved to verify that the original project outline still met their needs (which it did not).

2. Open communication: Not just between departments but within departments. If there had been more communication among our own department someone would have been able to pick up the pieces of this project much sooner than two years later.

3. Project Team: By including other people as project team members we would have been able to avoid losing as much information as we did when my co-worker left because other people would have been meeting with and discussing the issues they encountered while working together on the project.

4. Oracle Documentation: Trying to get each module's DBI up and running with accurate data has been somewhat of a challenge. When running a data load some of the processes fail with error but when researching the error on the internet or on metalink I am only able to find three or four links where someone received the same error, however their error was related to performing transactions in the system and not to a data load in DBI. I've also studied the DBI implementation guide and the DBI users guide to try and troubleshoot our issues but once again there is hardly any info that explains errors we receive or issues we encounter. I do understand that trying to provide thorough documentation for each and every module in the E-Business Suite has to be a gargantuan project and I do appreciate what documentation is available via the implemenation and users guide but it always seems to be that the troubleshooting guide is the document that oracle forgets to provide (maybe their in colusion with the consulting industry).

Hopefully going forward, as I work on and implement different projects, I'll remember to follow my own advice so others won't run in to the same issues I'm dealing with if they end up needing to finish a project that I started and left incomplete.