Software Documentation Process Improvement

ISMG 6040 Spring 2011
Dr. Judy Scott

Margaret Irene Wallace
May 5, 2011

Contents 1. Executive Summary 3 2. Organizational Overview 3 3. Competitive Environment & Strategy 3 4. Oracle’s Fusion Middleware Department 4 5. Business Process Problem Discussion 5 5.1 Project Roadmap 6 6. Results & Findings 8 6.1 Understanding the Current Process 9 6.2 Redesign – Requirements and Design 12 6.3 Oracle 11g – BPM Criteria and ROI & Success Criteria 15 6.4 Develop, Test, Implement, Train 18 6.5 Coping with Cultural Resistance 19 Appendix A: Modeling Experience 20 Appendix B: Process Description 23 Appendix C: Inputs and Outputs 24 Appendix D: Governing Rules for Process Steps 25 References 26

1. Executive Summary
The process for creating and publishing software documentation at Oracle is lengthy and involves several roles and departments. The software documentation departments and the number of products they are responsible for have grown tremendously over the years due to acquisitions. However, the documentation process and its tools have not scaled well. There is no overall set of tools for the entire process. Email is the primary communication method, and is the basis for routing work from one step and role to the next. These steps are not automated, and the steps which are automated use out of date, non-integrated tools. The process is overdue for a comprehensive analysis and redesign.
In the analysis of the process the team determined that most of the inefficiencies could be addressed with new tools and an overall BPM solution to integrate the multiple departments that may be spread across the world. A BPM system will eliminate much of the lag time in the current process and electronically notify process users of tasks in need of attention. A BPM system can handle the routing of the process tasks, document conversion, and publishing. Implementation of better tools and a BPM system will eliminate the majority of human error associated with workflow.
Oracle already produces a robust BPM product. Licensing and support costs should be greatly reduced making the Oracle BPM Suite 11g the most economical, comprehensive, and successful choice for the Fusion Middleware Documentation Department at Oracle.

2. Organizational Overview
Oracle is the second largest software company in the world. It is publicly held and traded with an annual revenue exceeding $9.7 billion. Oracle is the world's leading supplier of software for information management, but it is best known for its sophisticated relational database products (notably Oracle9i), which are used in Fortune 1000 corporations and by many of the largest Web sites. Oracle's relational database was the world's first to support the Structured Query Language (SQL), now an industry standard [1]. The majority of its software products are large, complicated products for business use. As such, they require extensive and accurate documentation for end users and administrators.
3. Competitive Environment & Strategy
Oracle operates within the very competitive software development industry in which the company reported total revenue increase of 36% to $8.8 billion in third quarter earnings for fiscal year 2011. Oracle’s top competitor, IBM reported record earnings in the fourth quarter of 2010, with revenue reaching $29 billion. Still, Oracle maintains a relatively simple M&A (Mergers and Acquisitions) policy which has allowed the company to build its line of product offerings while strategically buying innovative companies. Not only does the strategy allow Oracle, and its competitors in the market, to obtain a customer base that increases market share and revenue – such as Oracle’s purchases of PeopleSoft, Siebel and BEA Systems [2] – but the strategy also allows Oracle to push into new vendor markets and to improve the company’s core capability. The success of this strategy is evident even outside of the software/hardware development market as demonstrated by the merger between Sallie Mae and USA group of Indianapolis. Two giant players in the education industry decided to merge seeking new opportunity for growth and intending to benefit from shear economy of scale. [3]
Oracle’s successful revenues and aggressive acquisitions have earned the company a sizeable market share. And while the company continues to expand its line of product offerings to consumers, the company’s documentation responsibilities continue to grow in direct proportion. Every product Oracle produces must be accompanied by documentation deliverables such as product information and user’s manual. The problem, however, is that the existing infrastructure supporting the documentation process at Oracle is inadequate. Although management may not identify a redesign of this process as an opportunity for measured improvement, end users certainly do. An investigation into end user experience within the Fusion Middleware software documentation department at Oracle revealed to this team that the majority of users, in a variety of roles, are not equipped with the tools to make them productive and efficient users.
4. Oracle’s Fusion Middleware Department
Fusion middleware creates scalable enterprise and web applications, and integrates different systems together to automate business processes. It also includes management technologies that extract information, and store it in repositories that enable sharing through Oracle's Enterprise 2.0 approach, secured with Oracle identity management. According to Oracle’s mission statement, the Oracle Fusion Middleware suite of standards-based software is the leading software infrastructure for building and deploying enterprise applications to provide better quality information and streamlined processes [4]. In considering the company’s mission statement, it was difficult for to imagine why the Oracle Fusion Middleware software documentation department would not implement one of its own solutions, Oracle Fusion Middleware 11g, to provide management with visibility into the documentation process, to automate and streamline workflow, and to integrate applications for different users involved in the documentation process.
Given the company’s consistent acquisition and expansion of Fusion Middleware products, the current documentation process is inadequate and will be the target of this team’s process redesign. The documentation process is one step in the larger process of getting Fusion Middleware products to market. But any given employee or unit or activity is part of a larger entity. Ultimately, those entities, working together, are justified by the results they produce [5]. As part of the larger Fusion Middleware division at Oracle, the software documentation department is at risk as the workload increases with product expansion, consequently putting the Fusion Middleware division, and the company as a whole, at risk when demand scales to a level which the current infrastructure cannot handle.
In order to continue to be profitable, efficient and competitive going forward, Oracle’s Fusion Middleware Department will need to institute some form of Work Flow software, and they will also need the flexibility which Business Process Management (BPM) brings so that management can rapidly change processes to meet changing demands. This team will illustrate through this project how BPM software can greatly improve the software documentation process at Oracle’s Fusion Middleware Division, and also explore several workflow automation and BPM solutions to determine which will be the most appropriate tool for Oracle’s Fusion Middleware Documentation Department (FMDD).
5. Business Process Problem Discussion
“A process is a bounded set of activities that are undertaken, in response to some event, in order to generate an output” [6]. There is a performance gap which exists between the current process, or As-Is process, and the way in which the process ought to perform once it is improved, or the To-Be process. The overall software documentation effort is broken up into several departments organized within product family lines. Although the high level steps and tools used by the different departments are the same, the details vary between departments. The process described and developed here is used by the Fusion Middleware Documentation department. This department has over 300 employees all over the world, and is responsible for hundreds of books covering hundreds of software products.
The process for creating and publishing software documentation at Oracle is lengthy and involves several roles and departments. The software documentation departments and the number of products they are responsible for have grown tremendously over the years due to acquisitions. However, the documentation process and its tools have not scaled well. There is no overall set of tools for the entire process. Email is the primary communication method, and is the basis for routing work from one step and role to the next. These steps are not automated, and the steps which are automated use out of date, non-integrated tools. The process is overdue for a comprehensive analysis and redesign.
5.1 Project Roadmap

Harmon’s text Business Process Change will serve as a model for the team to follow a traditional system implementation methodology in the implementation of the BPM system within Oracle’s Fusion Middleware Documentation Department.
.
Figure 1 – Project Roadmap

5.1.1 Choose a Process as a Team & Understand the current process:
Team members collectively determined that the software documentation process at Oracle’s Fusion Middleware Division, of which a team member is an employee capable of relating process details, was a process in need of improvement and redesign. A project road map will be determined. The current process will be modeled using both Ultimus and TIBCO and reviewed with team members most familiar with the process until all team members have a full understanding of the process as it stands now.
5.1.2 Analyze the current process:
The current process will be broken down into smaller areas to identify bottlenecks, gaps, and areas where unnecessary manual steps are present. Conduct interviews with process users and stakeholders. Potential automation options will be evaluated and worked into the new process proposal. Potential BPM solutions are researched, and a product is identified for the workflow and document management requirements.
5.1.3 Model the proposed process:
The information learned in the analysis of the current process will be used to model the proposed process changes. Design of the “should be” processes. the processes outlined in Harmon’s book as well as those researched in order to recreate an improved documentation process. Improved process decreases the amount of time required to produce documentation deliverables, eliminates bad link publication, and reduces the number of failed document publications.
5.1.4 Develop, Test, Implement and Train:
Development, testing and implementation of the system in addition to employee training. Since the BPM software to be purchased is an Oracle product, system experts and support will be available. Implementation of processes with the new software will be assisted by in-house experts, and testing will occur as the system reaches users. A separate committee will be assigned to employee development. This committee will focus on building, piloting and then implementing a consistent training program across all branches for the new processes and tools.
5.1.5 Coping with Cultural Resistance:
There are several foreseeable adversaries to the implementation of a new set of tools and a BPM system. The current IT staff, two overlapping engineering groups, who maintain the current tools are also responsible for the development of the current tools. Some, if not most, are highly invested in these tools and will resist change. However, most users realize that better tools and automated workflow will make the department more effective and productive. In addition, the choice to implement an Oracle BPM solution will be met with much less resistance by management than suggesting utilization of a competitor’s solution. Therefore the team believes the launch of the process redesign and improvement will be welcome.
6. Results & Findings
The following sections will discuss the results and findings of the steps identified in section 4.1, the Project Roadmap.
6.1 Understanding the Current Process
The current process within the FMDD is functional, but will not perform as the demand for documentation increases. Metrics were defined by the team to measure process improvement in the software documentation process. Please refer to Figure 2 below for definition of the opportunity for improvement (metrics), the threat that opportunity faces without improvement, and the action required to eliminate the threat.

Opportunities (Metrics) | Threats | Action Required | Reduce overall document production time | Increasing workload for FMDD is a risk for current scalability | Implement BPM | Improve efficiency of work flow and employee accountability | Risk losing employees because of frustrating work practices and lack of recognition | Install workflow component of BPM with routing rules and secure sign-ons | Eliminate document publication failures | Wasted time & resources, unpublished documents are not accessible to consumers | Implement BPM to automate & confirm success | Eliminate bad link publication documentation | Human error is not being identified and corrected | Implement BPM to Identify Conflicting Links & Auto Correction of Bad Links | Provide production measure to management | Process is inefficient & management has no visibility | Implement BPM |

Figure 2: Opportunity for Improvement in Documentation Process

Analysis of the current documentation process yielded a defined set of requirements for the redesign and implementation of a BPM solution. The documentation process is triggered when either a new software product (or a new version of a product) is planned, or when the existing documentation for an existing product is deemed insufficient. A new software documentation set must be written. The product team managers gather to determine the number and types of documentation deliverables based on the size and of the product and the end user roles. The deliverables are determined to be part of an existing library, or it is decided that a new library will be created for them. Typically, if the documentation relates to a new software product, then a new library will be created, whereas if the documentation is for improvement to an existing product, then an existing library will be utilized. In this step, product team managers also assign a part number for each deliverable. Once the documentation deliverables are determined and part numbers assigned, the product development team identifies the SME’s (subject matter experts), writers, and project or program managers are identified within the team to assist in the documentation effort. The software documentation team identifies the writers for each deliverable. Communication among the product development team and among program managers occurs only via in-person and email communication.
The program manager for the writing group may act as project manager, or one may be assigned from either the writing or development teams.
Next, the writers are commissioned to draft a TOC (table of contents) for each deliverable. If a previous version of the documentation exists, that TOC is used.
If this is a new product, an initial TOC will be drafted by the writer. Documents are emailed individually by writers to program manager as they are completed. The program manager may be supervising a number of different documentation processes at once, and utilizes email folders and desktop features to keep projects organized. The TOC is then revised during meetings with the writers and SMEs and revision continues until the product team approves the TOC.
Next the writers begin writing the content for each section of the TOC. The writers contact the SMEs as needed during the writing. Sometimes new sections may be identified during the writing, in which case the TOC must be modified and re-approved. Re-approval often delays the project, as request emails often sit waiting for attention from one individual, barring the writers from moving forward.
As each section draft is completed, it is posted to a review site, where it undergoes technical reviews by SMEs, and may be subject to optional editorial reviews. Should there be edits to the draft, the document is sent back to the writers for edits, and posted again to the review site. SMEs are not consistently notified when drafts are re-posted after edits are made, and documentation often stalls in this review step on the review site. During this step, links to existing content are added during the completion of each section. The current process results in human errors which, with no system in place to identify them, allow bad links to make their way all the way through to publication. After all sections are done for a deliverable, final approval of the document must be obtained, and the final version is posted for review and approval on the review site.
The process moves to the production staff for the final steps, which in this teams’ analysis suffers most from lack of BPM. During library aggregation, all the completed deliverables are assembled into a library. Documents must manually be checked into the source control system. During transformation, the source content for the library is transformed into the needed output formats manually. HTML output is always required, and PDF output is often required. A list of section target IDs (to allow other documents to link into these) is also manually generated during the transformation step. An index must also be manually created for the library. The link target IDs are added to the link database without review. The link target IDs are added to the database manually by the production staff. Finally, the library outputs are published to the Oracle Technology Network (OTN), and the outputs are examined on OTN to ensure all deliverables were published. Publication failure to the OTN occurs on occasion, and verification by writers is manual, prone to human oversight and error. Figure 3 below illustrates the current As-Is process which this team believes serves the process well in structure, but is in need of a BPM to streamline and automate steps and notifications currently handled by outdated tools. The process is subject to human error and availability, and a BPM solution, as we will demonstrate, will greatly improve process efficiency and productivity.

Figure 3: As Is Process – High Level Diagram

6.2 Redesign – Requirements and Design
The team determined that the documentation process is inefficient, using out of date tools, and is in need of reengineering. The team decided to evaluate possible Business Process Management Systems that will eliminate the use of email and electronically notify process users of tasks in need of attention. The BPM system will handle routing of workflow, document conversion, and publishing. Product managers, SMEs, writers, and production staff will use this system. The solution will encompass all steps from book initiation through publishing and final approval, and the only users outside of the department will be the Product Development teams. Because the system will allow visibility via a manager dashboard, tasks which are delaying progression of process will be identified and re-routed or additional notifications will be sent to the user, depending on the role needed to fulfill the task. Since management will have more visibility into the process via a dashboard, users will be held responsible for completion of the task, and management will be better equipped to evaluate employee performance. The system will also greatly reduce the occurrence of failed publications and bad links.
Since the team is dealing with a very human-centric process, implementation of the system will eliminate the majority of human error associated with workflow, specifically, the process will no longer be subject to manual routing of work via email. Notifications and queues will be utilized for deadlines and reminders, and work will not remain ignored in an inbox. Instead, the task will be re-routed for completion. The system will offer a social component, giving users the option to connect with their peers, and building a culture of company kinship, while allowing users to quickly connect on pressing issues. The system will also allow for rapid changes in the process of handling issues, including changes in deadlines and priority levels. Furthermore, all instances entered into the system will be saved, which will allow process users to access the information if necessary in the future.
As an end result, our BPMS should achieve a level of process efficiency that is impossible given the current process tools and functions. Users will no longer need to concern themselves with the responsibility of routing work, they will instead focus on the work itself. Management will be aware of progress on projects and employee performance, and human error will be virtually eliminated. Figure 4 below illustrates the To-Be process in the software documentation department. The new process incorporates workflow automation and EAI to solve the major issues.

Figure 4: To-Be Process High Level Diagram

The team reviewed several types of workflows systems and determined that the process required a capable workflow tool, as defined by Khan [7]. With the process, and the department’s goals and limitations in mind, the team researched several possible tools. The first option, BPLogix, offered a web-based interface that allows business users to define and graphically model workflow processes, as well as a workflow management system which integrates with existing user directories and applications [8]. The team also considered Process Maker, which also allows business users to create and map fully-functional workflows, and a high degree of database connectivity. The tool can readily interconnect with legacy systems, including document creation and management applications [9]. Since the department operates within Oracle, it must abide by the company guidelines. Therefore, selection of a web-based solution was out of the question, and the tools, despite having the capability to improve the process, were rejected by the team. The solution, as defined by Oracle company mandate, must be able to utilize Java and Web Services APIs, cloud solutions are not acceptable, and the company prefers Linux and Solaris serves, and an Oracle database. Consequently, the team looked to an in-house solution in Oracle’s BPMS 11g. The choice to recommend a competitor’s solution would be met with too much resistance, and the benefit of in-house experts is invaluable.

6.3 Oracle 11g – BPM Criteria and ROI & Success Criteria
The Oracle solution meets all of our process redesign needs, and fulfills Khan’s criteria for BPM completeness [10].
6.3.1 Graphical Designer:
Oracle BPM Suite 11g is capable of designing workflow maps for the documentation process, with clear indications of the dependencies, conditions, and sequences in which tasks must be performed from initiation of new document creation though publication of all documentation deliverables. The model that is designed in BPM Studio is a ‘what you see is what you execute’ (WYSIWYE) model that eliminates synchronization issues between runtime and design time modifications – it is the same model. No translation is necessary to execute the design model [11].
6.3.2 Collaborative Design:
Oracle’s BPM suite utilizes the Process Composer to enable collaborative design and development. This ability to include multiple users of the process in the design will greatly increase the speed at which the processes are designed, and ensure process accuracy through user feedback. Bringing the users into the process design will also help to create an accepting environment for the implementation. The Metadata Services (MDS) repository stores deployed applications and components as well as projects and project templates for both BPM and SOA [12]. The system wholly supports collaborative design and development.
6.3.3 Modeling:
With Suite 11g, the software documentation department will be able to easily model the approval and review processes that take place throughout the project lifecycle. The routing of work and automation are also easily modeled. In its simplest form the graphical notation looks like traditional swimlane diagrams, and therein lies its attraction to business users [12]. The defined business process dictates the entire modeling process, which ultimately leads to the successful implementation of the product. The modeling capability of 11g scales for a wide variety of events and includes graphical modeling for event handling, which is important for modeling exceptions.
6.3.4 Multiple Client Interfaces:
Important to any organization or department, the ability to tailor the user interface to different end users is very important. Oracle 11g offers customizable user interface [11]. Product Managers will see metrics and progress on their home screens, while writers will have customized interfaces highlighting tasks and social capability. Participation in the documentation process will be improved though an interface which is easy to use and customized to a role’s specific work environment.
6.3.5 Business Metrics and Monitoring:
The ability to modify and optimize business processes based on reporting and monitoring is a key aspect of business process management, especially for a workflow system. With Oracle 11g, the dashboard function provides the capability to spot exceptions, determine which in-boxes are full, and where and when processes may become stalled. In addition, cost and time metric reporting of the system must also be available to management. The system gives management the capability to determine the productivity of both the system and the workers.
6.3.6 Web Services and Integration:
When automated systems perform the task in place of people, task time is greatly reduced. In the case of the documentation department, the BPM suite will assume responsibility for linking documentation as well as publishing the final product to the OLN. This will not only greatly reduce task time, but will also reduce the number of errors. 11g supports both Web Service APIs, Java and other integration approaches [13].
6.3.7 Database Connectivity and Scalable BPM Server:
Businesses store vital information in databases [10]. Oracle Suite 11g offers a dynamic set of adapters provides market-leading applications and database connectivity [14]. Connectivity to databases is essential to the speed and efficiency of a business process management system. Because Oracle is already a leader in applications and middleware, the documentation department can build and integrate its applications fairly effortlessly. The Oracle solution will meet the increasing demand of the documentation department by scaling with the number of transactions being performed quickly and reliably by the BPM server.
6.3.8 ROI for High Budget 11g Solution & Success Criteria: Salary costs: 4 FTEs (1 project mgr, 1 analyst, 2 developers) for 6 months = $200kOther costs: $10k licensing (maybe) + $50k hardwareBenefits as time: 10% better review time, 50% better publishing timeBenefits as $: $1500/book/year, or about $300k/year savingsROI first year: ($300k-$260k)/$300k = 13% |
Figure 5: ROI calculation
The team will evaluate the success of the implementation based on three KPIs (key process indicators). First, the review times for documentation, both the initial TOC review, and additional reviews, will be reduced by 10%. The BPM will accomplish this by automating work flow and notifying SMEs when a document is pending review. Next, the publishing time will be reduced by 50%. The BPM will accomplish this by eliminating human involvement in this step. The document will automatically be published to the Oracle network. Lastly, the frequency of broken links will be reduced to 1/100. The BPM will accomplish this by identifying human error and automatically correcting faulty links. The following figure illustrates this success criteria in the process. Since the lag time for several steps will be greatly reduced, the team hopes to see a significant improvement in overall process time for documentation, from initiation through publication.

Figure 6: Success Criteria Process Points

6.4 Develop, Test, Implement, Train
Once management sponsorship was gained through a presentation of the business case by the team, the project was ready for development, testing, implementation, and training. The initial writing steps will use the same tools and procedures, but will have a BPM layer to aid communication and track status, whereas the final publishing steps have been redesigned using the new solution. A small team is assigned to project implementation full time, and a subset of writers will participate as the implementation reaches the testing phase. The BPM rollout will emphasize testing and fixing problems in one area before moving the project on to the next.
Change management initiatives and communications will become very important as the project rolls out, and the implementation will begin in two parallel efforts. Implementation of the BPM layer for the writing steps will occur as the IT team begins the rebuild of publishing tools to be integrated with 11g.
Once the publishing tool rebuild is complete, the BPM layer will be expanded to those steps in the process as well. Publishing tools and BPM layer will be tested on just a few books initially to work out the obstacles. Finally, the transfer of all writers to the full system will occur once the solution is performing as intended. Training will be mandatory, and the focus will be on continuous improvement.
6.5 Coping with Cultural Resistance
The writers in the FMDD seem frustrated with the current tools and will welcome better tools, however cultural resistance is a factor for which the team has prepared. Mitigating resistance will rely heavily on training the users. Since the process is transitioning from a frustrating human centric workflow to an automated workflow, the team anticipates inter-employee tension will decrease significantly and has the potential to increase individual productivity, leaving peer communication a more social opportunity in the department.
The product engineering groups want to minimize the time that developers must spend on documentation and should also welcome better tools. However, some of the IT staff are very invested in the current tools, since they developed them. Coping with this resistance will require assigning some of these individuals to the rebuild of the new set of tools. This way, the staff can invest their egos in a new and better set of tools. Finally, management resists spending money, but since the BPM solution is an in-house product, licensing and support costs should be greatly reduced making the Oracle BPM Suite 11g the most economical, comprehensive, and successful choice for the Fusion Middleware Documentation Department at Oracle.

Appendix A: Modeling Experience
Overall, the team thought that the Tibco modeling tool (see Figs 3-5) was the superior process modeling tool as compared to Ultimus. Therefore Tibco models are included in the final report, while the Ultimus Process map is only included at the end of this Appendix.
The team had some prior experience modeling various processes using Visio and Microsoft Project, although no one had ever used an actual BPMS or any BPM modeling tools. The team found the Ultimus product to be difficult to use at first. We were expecting to see a modeling toolbar on the main screen. It took some time to find it, and even once it was found it was not obvious what all the components were. The Help documentation cleared up some of this, but even the documentation was pretty sparse on some details. For example, it has a very small explanation of how to use the maplet component, and it has almost no documentation which describes in detail how to use the various properties which are available for each component. We found that significant trial-and-error time was required to get anything to work. The process for generating the documentation seemed onerous too - you have to generate an XML template in order to get the product to generate documentation for your process. It did have an easy way to save the process as a spreadsheet, but since Excel was not available on the test PC there was no way to see what was in the spreadsheet. The team agrees that the Ultimus product is a mediocre piece of software. The modeling graphics were fairly crude, and really useful features which are available in higher end software such as context-sensitive help were not available. The TIBCO Business suite on the other hand, has two interfaces – one for “Analysts” and one for “Designers”. The model shown in this report was created in the Analysts view. The team found the interface to be fairly straightforward and the help documentation to be very useful. A BPM project in TIBCO Business suite contains Model Application Archive (.maa) files which can be passed back and forth from the Business Analysts to the Designers. A Business Analyst typically creates the file and creates the models for the process and then passes these onto the Designer who adds the details for execution. Three types of models are available in a Model Application Archive – Process Packages, Business Object Models and Organizational Models. For this project, the team focused on the Process Package to create a model for the software documentation process.
Once a new Process Package is created, the palette is easy to use to add tasks, connections and gateways to a new model. The team used the modeling tool to define the process “As-Is” (shown in figure 3). After roughly defining the process, the owners of each task are defined using any people defined in the organizational model. The duration of each activity can also be entered by choosing the activity and editing the properties right in the editor. Overall, the interaction with the process editor is quick and easy. TIBCO allows you to create reports on the fly – it will automatically export images of the models in a project and also create html documents containing information about the processes, participants in the processes and any data associated with the models. These could be created for a team to review and posted somewhere central as a process is analyzed or created.
The team found the TIBCO Business Suite easy to customize and intuitive, and found many features that aid a business in their analysis and automation of processes.

Ultimus Process Map

Appendix B: Process Description 0. Starting triggers (one of the following): a. A new software product (or a new version of a product) is planned. b. The existing documentation for an existing product is deemed insufficient. 1. A new software documentation set must be written due to one of the triggers identified above. 2. The number and types of documentation deliverables are determined based on the size and users of the software product. a. The deliverables will be part of an existing library, or a new library will be created for them. b. A part number is assigned for each deliverable. 3. The Subject Matter Experts (SMEs), writers, and project or program managers are identified. c. The product development team identifies subject matter experts (SMEs) within their team who will assist with the documentation effort. d. The software documentation team identifies the writer(s) for each deliverable. e. The program manager for the writing group may act as project manager, or one may be assigned from either the writing or development teams. 4. A draft Table of Contents (TOC) is obtained for each deliverable. f. If a previous version of the documentation exists, that TOC is used. g. If this is a new product, an initial TOC will be drafted by the writer. 5. The TOC is revised during meetings with the writers and SMEs. h. Revision continues until the product team approves the TOC. 6. The writers begin writing the content for each section of the TOC. i. The writers contact the SMEs as needed during the writing. j. Sometimes new sections may be identified during the writing, in which case the TOC must be modified and re-approved. 7. As each section draft is completed, it is posted to a review site. k. Technical reviews by SMEs. l. Optional editorial reviews. 8. Links to existing content are added during the completion of each section. 9. After all sections are done for a deliverable, final approval of the document must be obtained. m. Final version posted for review and approval on the review site. 10. Library aggregation. All the completed deliverables are assembled into a library. n. Documents must be checked into source control system. 11. Transformation. The source content for the library is transformed into the needed output formats. o. HTML output is always required p. PDF output is often required q. A list of section target IDs (to allow other documents to link into these) is generated during the transformation step. r. An index must be created for the library. 12. Link target addition. The link target IDs are added to the link database. 13. Publishing. The library outputs are published to the Oracle Technology Network (OTN). 14. Verification. The outputs are examined on OTN to ensure all was published.

Appendix C: Inputs and Outputs Process Step | Inputs | Outputs | Need for documentation identified | Product details, names, and release dates | New documentation project started. | Deliverables determined | Product details, product size, product users | Library definition part number and title. | SME’s and writers identified | Project scope details | All team members identified | TOC drafted | Existing TOC if there, product details if not | Draft TOC for each deliverable | Revise TOC | Draft TOCs | Approved TOCs | Write content | Approved TOCs | Draft sections | Post draft to review site | Draft sections | Approved sections | Add links | Approved sections | Sections with links added | Final approval | Collected sections | Approved books | Library aggregation | Approved books | Library of books | Transformation | Library of source content | Library of viewable content, index, and list of target IDs | Link target addition | List of link target IDs | Updated link database | Publishing | Viewable library | Viewable library on OTN | Verification | Viewable library on OTN | Verification all content is there |

Appendix D: Governing Rules for Process Steps Process Step | Rule | Need for documentation identified | Software product must be approved and have a release date | Deliverables determined | Deliverable types are dependent upon software products and user bases. For example, some products require Help Sets and User Guides and others don't | SME’s and writers identified | Left to management’s discretion and available personnel | TOC drafted | Use existing TOC if available | Revise TOC | No writing takes place until TOC is approved | Write content | New sections identified after TOC approval require re-approval | Post draft to review site | SMEs assigned to each section must approve on review site | Add links | Links assigned at writer's discretion | Final approval | Final approval provided on review site | Library aggregation | Library formatting rules | Transformation | Specific transformation tools used | Link target addition | Specific tools used for link targets | Publishing | Specific tools used for publishing | Verification | Writers approve published content |

References

[1] [Online]. Available: http://searchoracle.techtarget.com/definition/Oracle

[2] T. Wailgum. (2008, March 12). Oracle's Merger and Acquisition Strategy Gets Some Respect. [Online]. Available: http://www.cio.com/article/195950/Oracle_s_Merger_and_Acquisition_Strategy_Gets_Some_Respect?page=2&taxonomyId=3000

[3] C. V. Brown. FastTrack IT Integration for the Sallie Mae Merger. [Online]. Available: http://vizedhtmlcontent.next.ecollege.com/ec/courses/34069/CRS-ISMG6040-3223384/cases/salliemae.pdf

[4] Oracle Mission Statement. [Online]. Available: http://www.oracle.com/us/corporate/mission-statement/index.html

[5] P. Harmon. “Business Process Change,” in Business Process Change, 2nd ed. Burlington, MA: Morgan Kaufman Publishers, 2003, pp 1-25.

[6] P. Harmon. “Process Levels and Levels of Analysis,” in Business Process Change, 2nd ed. Burlington, MA: Morgan Kaufman Publishers, 2003, pp 198.

[7] R. N. Khan. “Workflow Automation,” in Business Process Management, A Practical Guide. Tampa, FL: Meghan-Kiffer Press, 2004, pp 30.

[8] BP Logix. [Online]. Available: http://www.bplogix.com/workflow-software/workflow-process.aspx

[9] Process Maker. [Online]. Available: http://www.processmaker.com/

[10] R. N. Khan. “Appendix A: A Framework for Evaluating BPM Products,” in Business Process Management, A Practical Guide. Tampa, FL: Meghan-Kiffer Press, 2004, pp 326-329.

[11] Oracle BPM Suite 11g: BPM Without Barriers. [Online]. Available: http://www.oracle.com/us/technologies/bpm/bpm-without-barriers-wp-190949.pdf

[12] Bruce Silver Associates. A First Look at Oracle BPM Suite 11g. [Online]. Available: http://www.oracle.com/us/corporate/analystreports/infrastructure/bruce-silver-bpm-suite-11g-083869.pdf

[13] Oracle Business Process Management Suite. [Online]. Available: http://www.oracle.com/us/technologies/bpm/029418.pdf

[14] Oracle SOA Suite 11g. [Online]. Available: http://www.oracle.com/us/technologies/soa/soa-suite/oracle-soa-suite-11g-198758.pdf