OracleAppsBlog
A day in the life of an Oracle Applications Consultant

Project Management

Friday, August 20, 2004

Oracle ERP implementation - the Douglas Omaha Enterprise Resource System (DOERS)

This post contains a review of the Douglas Omaha Enterprise Resource System (DOERS) site and highlights useful documentation which can be downloaded. 

Last week I came across a really good site documenting an Oracle ERP implementation at the City of Omaha which has been named the Douglas Omaha Enterprise Resource Systems (DOERS). According to their site and related documentation: -

The City of Omaha, Douglas County, and the Omaha Douglas Public Building Commission are participants in a joint implementation of Oracle HRMS application suite, a project called DOERS (Douglas Omaha Enterprise Resource System). The DOERS project is a phased implementation and Oracle HRMS is Phase 3 of the total project.Phase 2, which includes Inventory, Grants Management, Projects and Public Sector Budgeting, began in early 2002. Phase 1, involving the Oracle Core Financials, began in early 2001 and includes General Ledger, Receivables, Payables, Fixed Assets, Cash Management, Purchasing and iProcurement.

Following is a summary and analysis of key areas of the site: -

HRMS

According to this section of the site: -

The City/County DOERS project continues building an Oracle Solution to integrate HR, Payroll, and Benefit functions with the new Oracle Financial modules. This initiative falls under the DOERS project umbrella specifically called Phase 3. This Phase of the Oracle implementation also named HRMS for Oracle’s Human Resource Management System has been made significant progress. Douglas County and the Omaha Building Commission went live on version 11.5.5 in January of 2004. Due to the complexity of this phase and limited resource availability the Go Live date for the City has been pushed back.

Here you will find two very good documents to download, namely the RD.020 documents for Human Resources and Benefits. The RD.020 Current Business Requirements is an Oracle AIM (Applications Implementation Methodology) document which is designed to identify and document current business processes and requirements. This document often incorporates a questionairre and is completed during the Definition phase of a project.

Inquiry and Reports

Contains business forms, chart of accounts and end user documentation and training material for Accounts Receivable, Accounts Payable and General Ledger.

Chart of Accounts

Here you can download the latest Chart of Accounts which is structured according to the following segments: -

  • Funds
  • Orgs
  • Activities
  • Assets
  • Liabilities
  • Fund Balance
  • Expense
  • Revenues

Current Practices

Here you will find the RD.020 documents for the various modules implemented in each phase of the project.

Future Processes

Contains the RD.030 documents for the following future processes: -

  • Payables
  • Purchasing
  • General Ledger
  • Fixed Assets
  • Accounts Receivable
  • Grants and Projects

The RD.030 document is an Oracle AIM document which is used to establish a process and mapping summary for your organisation. It is normally completed within the Operations Analysis phase of the project lifecycle. In this task, you create the repository for key project findings and decisions that occur during the process and functional requirements gathering activities.

Wednesday, June 16, 2004

Download Oracle AIM (Applications Implementation Methodology) Software and White Paper

Oracle AIM (Applications Implementation Methodology) is Oracle’s project management methodology. This post contains links to where you can download Oracle AIM software and an Oracle AIM White Paper.

Oracle AIM consists of a project management methodology together with the underlying documentation templates that support the tasks you perform within this methodology. This combination of a methodology together with documentation templates makes AIM a powerful tool for assisting implementation participants in running and managing projects successfully. The methodology can be used for any other software implementations but obviously the true value of AIM will be only be realised when it is used in conjunction with the Oracle specific document templates. The documentation templates are available in the AIM software and the methodology is clearly outlined in the AIM software documentation.

The Oracle AIM Front End Displaying Project Phases and Processes

The Oracle AIM GUI which allows you to navigate to the documentation templates

Download Oracle AIM Software (23.8MB). This software provides you with the methodology as well as documentation templates that are needed to run your Oracle Applications projects. Sadly this product doesn’t seem to have been updated for version 11i. Two tips I should give you about the installation and use of the tool - firstly, it doesn’t seem to work on IE6 so try and install it on IE5.5 or lower. Secondly, make sure that your macro security is set to low in both Word and Excel as AIM will need to run certain startup Macros that install additional menus. The software contains all the documentation you will need to learn how to use the product and you can also download my white paper which will give you a short overview of how AIM works.

Sunday, June 13, 2004

Legacy Management Part B

All projects start with some level of legacy management, be it software development or ERP implementation, it involves legacy systems and their future role as business process base. The business process that is more or less embedded in legacy is of importance viz a viz proposed automation too. To begin with our projects we must develop a sustainable approach to legacy management.

An article from the Gartner Group:” Building an IT Strategy When There is no Clear Business Strategy” (Gartner - John Mahoney) states following rules of the game:

a. Best Practices


1) Connect all IT proposals to business goals and metrics or to the necessary base infrastructure, if necessary, by establishing new measures. Use these connections to prioritize and measure IT proposals in business terms. Keep the model simple and flexible.
2) Communicate frequently and clearly to ensure that all-important issues are considered and to avoid misunderstandings.
3) Limit strategy creation to a predetermined period, and review and update the strategy later if necessary as circumstances change. It is better to have an initial direction and a sketch map so that the journey can start rather than wait until the whole journey is mapped in detail.
4) Ensure IT planners are represented in business-strategy planning teams from the start and throughout the process.
5) Engage top leaders in the enterprise to resolve strategic ambiguities and to manage uncertainties and risks.


b. Common Errors


1) Attempting to create inappropriate detail and false certainty.
2) Building or expressing IT strategy in terms of technology drivers rather than business objectives and benefits.
3) Failing to connect IT strategy to a business value model.
4) Creating the impression for enterprise business leaders that the IT organization is trying to take over business planning.
5) Spending excessive and uncontrolled time on consultation and consensus building.”
6) Worst of all, subjecting professional and technical decisions making to non technical staff

Bottom line—Back to Basics! Business Planning and Analysis are key messages that need to be embraced by all levels of management, and involvement is mandatory. Successful implementation of any chosen technology will only be successful if the people using the technologies are committed and trained, and management has provided a clear message on the use of the technologies. There is no magic, just plain old common sense and experience. Effective plan must be:

1. Must be rapid process.
2. Provide brief and clear output
3. Integrate context to greater and detailed strategic plans.


A. First Step: Gain Understanding of Organizational Operations.


Our first step should be one of gaining understanding. We need understanding of all of our current assets wherever they may be, human and technical or otherwise.

1. Understanding our human capital means we need to understand where the expertise and skills are and how they relate to our inventory of software and hardware.
2. Who in our organization has the business expertise relating to: vital legacy applications, installed packages, new services, and Web applications?
3. Who in our organization has the technical expertise for these assets?

Understanding our technical software assets means:

1. Making and verifying an inventory of all existing applications
2. Including the technology requirements and skill sets required for each.
3. The business functions that each application supports.

Having this matrix of resources, applications, skill sets and human capital, we will be able to see where the most important business functions are supported and how. We need to catalogue what we have, where it is, what it does, what technology is in use, what database management systems, what data does it contain, what data does it own, how does it interact with other assets, what is the timing of events. This would generate an X-Ray of our IT activities and assets, giving us a deeper look into the overlaps and missing pieces and huts help us understand how to go forward.


B. Second Step: Planning of Proposed Operations.


Planning change is different from standard project plans in the sense that it necessitates inside-out approach. This will be a new kind of planning, tactical and strategic for an ever-evolving portfolio. Not a static or linear model, but a perpetual, adaptive and evolving model. Legacy management is not a one time issue or resolution, but developing a strategy of interoperability and interpolarity. A service oriented strategy to match the new model with our service oriented component architectures that we should adopt. Our project management techniques will need to plan for collaboration from many different knowledge domains—business and technical. We will need to develop and adapt to a multi-path multi-disciplinary integration methodology.

Skills management and detailed training plans will be very important, as our assets will lie in many different technologies. Strong architectural skills will be of the essence. New tools may be required to support the detailed cataloging of the business models and the technical components that support them.


C. Third Step: Produce Architecture for Organizational Operations.


Perhaps the most important step will be the production of the architecture that supports our new outlook, along with the plans on how to map our current assets to it. Using new integration methodology and business modeling tools we need to develop our new business model based on this new thinking regardless of what currently exists. This leads us to go for a through upgrade of applications, rather than to adopt isolated instance of what is new; an Enterprise wide scope.

Every asset we currently own is a possible component of our architecture. Whether it is new or legacy or a purchased application component does not matter. What matters is, it has a usable component that satisfies the business need. Our understanding of these current assets will be vital as we go forward. Our previously developed inventory can be used and we will need to dig into each application to find the real services that can be reused.

Once we have this new architecture and can see how our current assets map to it then we need to implement. We will use a variety of techniques and tools to isolate and wrapper functionality from legacy applications preferably using non-invasive techniques. We will most likely employ AIM and middleware tools, which already have process workflow designers built into them. We will make use of wrappers and connectors to purchased solutions. And we will continue to develop new services with our choice of component and service oriented development tools. All this should be technically and professionally wrapped in any good RFP.
Our ultimate target is an ERP with loosely coupled, workflow based, service oriented portfolio of software assets, which is flexible enough to manage rapid change over time and support new business practices as rapidly as they occur and is achievable.


D. Legacy Component Services and Future.


Yet it does not mean that the thousands of dollars invested in legacy applications must be wasted. Duplications stand to go. Those legacy assets can still be utilized to deliver new services meeting our time to market goals and possibly at a lower cost than totally new development. .


E. Back to the Basics.


Organizations today are looking to new technologies to improve their organization’s competitiveness. That’s why IT must not only support, but also shape every company’s ability to manage customer relationships and business partnerships, and to introduce innovative products, services and distribution channels. And move away from the 80’s—“isolated islands of technology”. With proper business analysis, organizations can progress cautiously, minimizing risk, and providing users with functionality they not only want, but also need! Through the business analysis process, IT infrastructure is enhanced with a clear set of “technology stakes” presented to the users, and constant review and updates to business processes manages changes in the business.

At the core of these changes is the internet computing model; a gradual shift from client/server. These objects provide IT with the ability to quickly and accurately model business requirements for end users and provide the basic building blocks for new functionality. These basic functions are available today in many new tested technology environments from J2EE tools, ‘Self Service Modules’ and its rival, .Net. So the question is not what tools can I use, but what do I want to accomplish with these new tools? “Back to the Basics!”

Wednesday, June 09, 2004

Legacy Management

It is fewer than often that we get a clean slate to start with automating business processes. This brings us face to face with Legacy Systems Management. In situations this Legacy is a blessing in disguise, at time it is pure source of annoyance, but i have felt all along that an effective Management will maximize gains in these Projects neverthless it will never be a single one time event in any organizations’ life. Through this site I intend to issue a series of documents, my experiences and exposures, first and foremost, in relation to ERP Project Management.

Legacy Management
Part A


1. The Task
“Modernization” is being in a perpetual state of responding to growing needs of time that is to say having a predominantly proactive outlook. It must avoid the telescopic view into distant future implying tunnel vision or a microscopic view with its reductionistic approach; both ending in disproportionate view of needs and resources. It should simply be a real life picture of technological needs. It is much more simple process of open and fair response in all times to all needs, growth potentials and technological advancement. Therefore change is responding to and being in perpetual visioning process. Change comes from within and not without. Yet at times legacy become dispensable, both in terms of human resource or software and hardware. How it is appropriate to dispense legacy is a tricky question below is an analytical approach to adopt “new” and dispense the “old”.

2. What is a Legacy?

Legacy systems are the information resources currently available or used in past in the organization. They include existing databases, operating systems, application programs and all other forms of hardware and software that a company may own. The prominent legacy applications on the some of the examples of legacy systems are:

1. File Systems Databases
2. Client Server Applications (especially if we intend to be proactive Client Server Technology will be considered legacy in a short while).
3. COBOL. Etc.


3. Forward Engineering Process

Forward engineering is a simple process through which systems are implemented in a fairly straightforward logical sequence, typically including analysis, design, construction, testing and maintenance phases. Forward engineering is a simple and straight forward for out of box applications, it is also the normal new systems. Yet to have a clean slate is more often thought than experienced in real life situations. It is often compromised by the existence of existing systems.


4. Reverse Engineering Process.

As a smart alternative to forward engineering, reverse engineering is an intelligent option when there is insufficient information to form a sound basis for a new system. This is results from:
o Knowledge in the legacy system may no longer be available in any other form
o No formal definition of a core business process
o Policies and procedures are non existent or irrelevant.
o Or procedures exist for no reason.
o Legacy Systems Lack basic documentation
o There is insufficient understanding of the business itself.

So Reverse engineering is a smart and intelligent option for acquiring critical knowledge of business processes from existing systems so as to specify and construct their replacements. This is not only sustainable process for meaningful change but also offers low risks. Especially if the organizational skill levels are inadequate to ascertain the modernization process; reverse engineering could be a safe and accurate option for change.

4. Incremental Modernization Processes.

“Big Bang” is not feasible even if desirable to change from a legacy to a new system in a single go. The modernization of legacy systems is usually complex, large, years long projects that pose significant financial, organizational and operational risks. Therefore, a ‘staged’ evolution from the legacy application to the new system over periodic intervals of time, ascertaining each stage, capitalizing on its gains and moving on to the next natural steps; is stable and productive approach. This would lessen the impact of the risks involved. The incremental approach reduces the percentage of introduction of ‘New Code’ into the percentage of ‘Old Code’ or Legacy Systems. This process allows to gradually increasing the ‘New’ to replace the ‘Old’.

Modernization of the legacy system is best achieved through critical guiding principles:
o End User Involvement
o Staged Developmental Approach.
o Time Management
o Predefined and Preplanned “Replacement of Systems”
o Periodic Testing.
o Empowered Smart Teams Management.

These guiding principles greatly improve the success and reduce the risks of taking the legacy system through a sustained incremental modernization project.


1. Managing Legacy and Modernization.

Software market has very aggressively responded to modernization requirements of IT industry and ushered in a series of tools which facilitate and increase the efficiency and effectiveness of systems, analysts, designers, developers and testers, which in turn benefits the enterprise.

Support for legacy environments for example old systems like COBOL is limited in terms of availability of tools; the business units that rely on older applications have genuine concerns on modernization. What organizations will need to do is mix and match tools and discover the right solution for the Migration part of ERP Project. These tools work wonders, with ability to generate code logic and provide a means to employ legacy ‘wrappers’, such as data wrappers, UI (User Interface) wrappers, and application wrappers. These wrappers encapsulate, or wrap, the legacy application and data resources.


2. Repositioning for Composite Applications.

IT staff treads on water, ever moving right under their feet, just to be the current waves they have to tread a very fine line of keeping afresh older knowledge base and acquiring new technologies. Rapid advancement and continual shifts in technology is a prize for organizations and nothing less than a nightmare for IT staff. New approaches, techniques and tools appear continually. New delivery mechanisms appear and affect current and future strategies.  An end user asking for new functionality to change from old one is not just a simple request anymore. It triggers a process of integration of the organized chaos that currently exists. It seems obvious that over time the role of the application developer has changed along with the strategy of the organization. We have to accept that we should now be called ‘application integrators rather than developers’. The job today is much more about integrating the assets we have than developing new ones. Integrating to deliver a business process that works smoothly while involving legacy, ERP and new application functionality delivered via any one or more of the user-interfaces that currently exist. We will rarely, have the opportunity to start from a clean slate. There is no such thing as clean slate in IT anymore. We have to refurbish our office ‘our self’ while working out of it, so are we not refurbishers?

As we take this challenge, luckily there is a continued growth of tools in the Enterprise Application Integration (EAI) market. At the heart of our integration strategy is a ground-reality-based approach for delivering and managing business chains and it has to be reflected in the use of the assets we currently own in information technology, with the need to provide highly coordinated functionality from many diverse applications in many more diverse technologies. The best way out is to employee business modeling tools. This would allow visualizing, catalogue and managing the vital scenarios, which happens to be ideally suited for the purpose.

“New project complexities go beyond the understanding of individuals, no matter how expert they may be. Integration teams will have to employ multiple methods that will include skills from packaged implementation, new development, traditional development, component development, legacy integration and reuse. ‘Project management in this buffet-style environment will present new challenges for co-ordination and measurement’. Cross-functional teams with non-linear tasks will be complex to manage. Many diverse skills, from legacy to wireless, may need to be employed in any one implementation, and are unlikely to be possessed by a single developer. “

We have to accept the challenge and understand that it will not be a simple straight line transition from PointA to PointB because when we get to PointB we will want to go to PointC. The magic lie is controlling the fusion reaction rather than leaving it unbridled and untamed wish list of automations. The challenge is to control this fusion of chain reaction and create an environment to control a continual evolution of application portfolio making as much use of the assets we have while continually planning to enhance and replace them as new challenges occur. The shift from a straight line transition to a continued evolution will help us understand how to plan and control this new componentized, multi-disciplinary workflow model before it controls and overwhelms us. Yet the good news is that this is probably the only work where input is equal to output; ideal machine and at times even better. (Hope I am not being too optimist about our potentials)

To be continued with part B of this paper; with a step by step approach to Managment of Legacy Systems

Page 2 of 2 pages  < 1 2