weew! another hard question..
It is very difficult to obtain consensus on a functional decomposition for any one application, much less across all the information systems within the entire corporation. That is because functional analysis requires identification and codification of how activities are performed. In short, the codification of style. This type of analysis leads to conflicts, power struggles, and endless nit-picking. In the end, nobody likes the results. Once, or if ever completed, both IBM and Martin use the resulting ISP as a foundation for identifying information systems. Building the ISP on top of such a foundation of discord cannot possibly result in stable, enduring information systems.For a long time relationship between information system functions and corporate strategy was not of much interest to Top Management of firms. Information Systems were thought to be synonymous with corporate data processing and treated as some back-room operation in support of day-to-day mundane tasks (Rockart, 1979). In the 80’s and 90’s, however, there has been a growing realization of the need to make information systems of strategic importance to an
organization. Consequently, strategic information systems planning (SISP) is a critical issue. In many industry surveys, improved SISP is often mentioned as the most serious challenge facing IS managers (Pavri and Ang, 1995, Beath and Orlikowski, 1994; Martin, 1993; Porter and Miller, 1985). Planning for information systems, as for any other system, begins with the identification of needs. In order to be effective, development of any type of computer-based system should be a response to need--whether at the transaction processing level or at the more complex information and support systems levels. Such planning for information systems is much like strategic planning in management. Objectives, priorities, and authorization for information systems projects need to be formalized. The systems development plan should identify specific projects slated for the future, priorities for each project and for resources, general procedures, and constraints for each application area. The plan must be specific enough to enable understanding of each application and to know where it stands in the order of development. Also the plan should be flexible so that priorities can be adjusted if necessary. King (King, 1995) in his recent article has argued that a strategic capability architecture - a flexible and continuously improving infrastructure of organizational capabilities - is the primary basis for a company's sustainable competitive advantage. He has emphasized the need for continuously updating and improving the strategic capabilities architecture.
Characteristics of a Quality ISP
A quality ISP must exhibit five distinct characteristics before it is useful. These five are presented in the table that follows.
Characteristic ------- Description
Timely -------- The ISP must be timely. An ISP that is created long after it is needed is useless. In almost all cases, it makes no sense to take longer to plan work than to perform the work planned.
Useable ------- The ISP must be useable. It must be so for all the projects as well as for each project. The ISP should exist in sections that once adopted can be parceled out to project managers and immediately started.
Maintainable ------- The ISP must be maintainable. New business opportunities, new computers, business mergers, etc. all affect the ISP. The ISP must support quick changes to the estimates, technologies employed, and possibly even to the fundamental project sequences. Once these changes are accomplished, the new ISP should be just a few computer program executions away.
Quality -------- While the ISP must be a quality product, no ISP is ever perfect on the first try. As the ISP is executed, the metrics employed to derive the individual project estimates become refined as a consequence of new
hardware technologies, code generators, techniques, or faster working staff. As these changes occur, their effects should be installable into the data that supports ISP computation. In short, the ISP is a living document. It should be updated with every technology event, and certainly no less often than quarterly.
Reproducible -------- The ISP must be reproducible. That is, when its development activities are performed by any other staff, the ISP produced should essentially be the same. The ISP should not significantly vary by staff assigned.
The ISP Steps
The information systems plan project determines the sequence for implementing specific information systems. The goal of the strategy is to deliver the most valuable business information at the earliest time possible in the most cost-effective manner.
The end product of the information systems project is an information systems plan (ISP). Once deployed, the information systems department can implement the plan with confidence that they are doing the correct information systems project at the right time and in the right sequence. The focus of the ISP is not one information system but
the entire suite of information systems for the enterprise. Once developed, each identified information system is seen in context with all other information systems within the enterprise.
Information Systems Plan Development Steps | ||
| Step | Name | Description |
| 1. | Create the mission model | The mission model, generally shorter than 30 pages presents end-result characterizations of the essential raison d=etre of the enterprise. Missions are strategic, long range, and a-political because they are stripped of the Awho@ and the Ahow.@ |
| 2. | Develop a high-level data model | The high-level data model is an Entity Relationship diagram created to meet the data needs of the mission descriptions. No attributes or keys are created. |
| 3. | Create the resource life cycles (RLC) and their nodes | Resources are drawn from both the mission descriptions and the high level data model. Resources and their life cycles are the names, descriptions and life cycles of the critical assets of the enterprise, which, when exercised achieve one or more aspect of the missions. Each enterprise resource Alives@ through its resource life cycle. |
| 4. | Allocate precedence vectors among RLC nodes | Tied together into a enablement network, the resulting resource life cycle network forms a framework of enterprise=s assets that represent an order and set of inter-resource relationships. The enterprise Alives@ through its resource life cycle network. |
| 5. | Allocate existing information systems and databases to the RLC nodes | The resource life cycle network presents a Alattice-work@onto which the Aas is@ business information systems and databases can be Aattached.@ See for example, the meta model in Figure 2. The Ato-be@ databases and information systems are similarly attached. ADifference projects@ between the Aas-is@ and the Ato-be@ are then formulated. Achievement of all the difference projects is the achievement of the Information Systems Plan. |
| 6. | Allocate standard work break down structures (WBS) to each RLC node | Detailed planning of the Adifference projects@ entails allocating the appropriate canned work breakdown structures and metrics. Employing WBS and metrics from a comprehensive methodology supports project management standardization, repeatability, and self-learning. |
| 7. | Load resources into each WBS node | Once the resources are determined, these are loaded into the project management meta entities of the meta data repository, that is, metrics, project, work plan and deliverables. The meta entities are those inferred by Figure 2. |
| 8. | Schedule the RLC nodes through a project management package facilities. | The entire suite of projects is then scheduled on an enterprise-wide basis. The PERT chart used by project management is the APERT@ chart represented by the Resource Life Cycle enablement network. |
| 9. | Produce and review of the ISP | The scheduled result is predicable: Too long, too costly, and too ambitious. At that point, the real work starts: paring down the suite of projects to a realistic set within time and budget. Because of the meta data environment (see Figure 1), the integrated project management meta data (see Figure 2), and because all projects are configured against fundamental business-rationale based designs, the results of the inevitable trade-offs can be set against business basics. Although the process is painful, the results can be justified and rationalized. |
| 10. | Execute and adjust the ISP through time. | As the ISP is set into execution, technology changes occur that affect resource loadings. In this case, only steps 6-9 need to be repeated. As work progresses, the underlying meta data built or used in steps 1-5 will also change. Because a quality ISP is Aautomated@ the recasting of the ISP should only take a week or less. |
Executive and Adjusting the ISP Through Time
IT projects are accomplished within distinct development environments. The two most common are: discrete project and release. The discrete project environment is typified by completely encapsulated projects accomplished through a water-fall methodology.
In release environments, there are a number of different projects underway by different organizations and staff of varying skill levels. Once a large number of projects are underway, the ability of the enterprise to know about and manage all the different projects degrades
rapidly. That is because the project management environment has been transformed from discrete encapsulated projects into a continuous flow process of product or functionality improvements that are released on a
set time schedule. Figure 3 illustrates the continuous flow process environment that supports releases. The continuous flow process environment is characterized by:
- Multiple, concurrent, but differently scheduled projects against the same enterprise resource
- Single projects that affect multiple enterprise resources
- Projects that develop completely new capabilities, or changes to existing capabilities within enterprise resources
It is precisely because enterprises have transformed themselves from a project to a release environment that information systems plans that can be created, evolved, and maintained on an enterprise-wide
basis are essential.
There are four major sets of activities within the continuous flow process environment. The user/client is represented at the top in the small rectangular box. Each of the ellipses represents an activity targeted to a specific need. The four basic needs are:
- Need Identification
- Need Assessment
- Design
- Deployment
The second characteristic flows from the first. Because these four activities are independent one from the other, the enterprise evolves by means of releases rather than through whole systems. If it evolved through whole systems, then the four activities would be connected either in a waterfall or a spiral approach, and the enterprise would be
evolving through major upgrades to encapsulated functionality within specific business resources. In contrast, the release approach causes coordinated sets of changes to multiple business resources to be placed into production. This causes simultaneous, enterprise-wide capability upgrades across multiple business resources.
Through this continuous-flow process, several unique features are present:
- All four processes are concurrently executing.
- Changes to enterprise resources occur in unison, periodically, and in a very controlled manner.
- The
meta data repository is always contains all the enterprise resource
specifications: current or planned. Simply put, if an enterprise
resource semantic is not within the meta data repository, it is not
enterprise policy. - All changes are planned, scheduled, measured, and subject to auditing, accounting, and traceability.
- All documentation of all types is generated from the meta data repository.
Time allocation: Each task should be paired with an appropriate time frame for completion. You should be aggressive but reasonable with your time allocation in order to ensure not just completion but competent work. For assistance in framing this timescale, use a program such as Microsoft Project, or just create your own Gantt chart – a helpful tool that shows how long it will take to
complete different tasks and in what order the tasks should be finished. Progress: You or a member of your management team needs to be in charge of monitoring each task’s progress and the completion percentage of each objective. When delays occur, try to get to the root of the problem. Did the person responsible drop the ball? Did he or she have too many responsibilities to handle? Did a third party, such as a supplier or the bank, fail to hold up its end of a deal? Adjust your Gantt chart appropriately to account for the delay, and make a note of the previous deadline and the reason it was missed. While the above steps may seem like overkill, the early days of a startup are critically important; it’s a time when good management patterns are set and also probably a lean era when revenue has yet to start rolling in. The more efficiently you start implementing yourbusiness plan, the more likely it is that you will survive this early period.
REFERENCES:
http://www.tdan.com/view-articles/5262
http://www.netmba.com/strategy/process/
http://www.tn.gov/finance/oir/planning/ispprocess.pdf
No comments:
Post a Comment