1 / 60

E-Biz/IT Automation

E-Biz/IT Automation. Kelly Halbert Verizon E-Business Business Solutions February 2001. Lights Out. The automation of manual activities to limit requirements for human intervention and consistently deliver desired results. Methodology. Data Center Definition.

whitcomb
Télécharger la présentation

E-Biz/IT Automation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. E-Biz/IT Automation Kelly Halbert Verizon E-Business Business Solutions February 2001

  2. Lights Out The automation of manual activities to limit requirements for human intervention and consistently deliver desired results.

  3. Methodology

  4. Data Center Definition • A data center is more than a computer room full of hardware and software. • In the new enterprise, “the network is the data center.” • The data center is comprised of the network and virtually everything attached to it—the computer center, workstations, desktops, and all related components.

  5. People, Process, Technology • “Time and time again, I have been brought into a data center operation after an unsuccessful deployment due to little or no design and planning. In case after case, mangers start with technology—the latest widget to solve their problems—and end up worse off. They buy the “solution” without proper evaluation, analysis, design, planning, and buy-in. The results are devastating: low morale, missed deadlines, wasted money, damaged relationships, and technical performance that is the same or worse than before the installation. This book is heavily front-loaded with information on all the aspects of project setup and planning. In fact, six of the seven chapters address the people process, and technology issues that must be addressed before deployment. If you don’t have time to scope, design, and plan your automation project, you surely don’t have time to deal with the problems you’ll create during implementation. Careful design and planning will reward you with an easier implementation—not necessarily without its challenges—but manageable overall.” Howie Lyke

  6. Benefits of E-Biz/IT Automation • Lower Personnel Requirements • Greater Reliability • Quicker Problem Resolution • Less Downtime • Lower Maintenance Costs

  7. Automation Considerations • Identify infrastructure components that are candidates for automation. • Research the level of complexity involved in automation. • Develop realistic and obtainable objectives for automation.

  8. Technical Architecture • Performance Monitoring and Capacity Planning • Disk Capacity Management • Storage Management • Event Monitoring • Network Management • Access Management • Job Scheduling • Version Release • Software Distribution

  9. Process Architecture • Production Acceptance • Problem Management • Change Management • Asset Management • Disaster Recovery

  10. Technical Architecture

  11. Technical Architecture

  12. Process Architecture

  13. Project Purpose • The purpose of the project is to automate the technical and process architectures so as to deliver more efficient processing, a reduction in the growth of staffing resources, and more effective operations management.

  14. Validation • Is there an executive-level directive to cut costs and headcount? • Does the culture support technology investment to reduce operating expenses? • Do you have funding in your budget for system management tools or any other type of automation? • Could other budgeted items be postponed to free up funds for the automation project? • Do you have any positive momentum to build from?

  15. The Gap Model • Before Picture – Current Automation • After Picture – Desired Automation • The Gap – Automation Initiative

  16. The Gap

  17. Before Picture • A description of the current level of automation for each technical and administrative process component, and a problem or opportunity statement that describes what can be fixed or improved via automation.

  18. After Picture • A description of the proposed level of automation for each technical and administrative process, and an associated problem or opportunity statement.

  19. Developing the “After” Picture • Development of the “after” picture starts by identifying the needs of three groups: end users, the applications development group in the E-Biz/IT department, and your data center staff. • The “after” picture is complete only after you have validated that the automation requirements support (or at a minimum do not adversely affect) the end-user, applications development, and data center needs.

  20. Needs Analysis • End Users – Business units include Sales and Marketing, Finance, Customer Service, Engineering, Operations, etc. Employees in these units are end users or business users. Their needs drive data center requirements for functionality, availability, response time, and connectivity, and may affect the automation requirements. • E-Biz/IT Applications Development – Applications groups are the primary interface between the data center and the business units and are generally the data center’s primary customer. • Data Center Staff – Consider operational and system management software needs of your Data Center Staff.

  21. The Gap • The difference between before and after. • The gap between what is currently in place and your new automation requirements.

  22. Gap Matrix (Technical)

  23. Gap Matrix (Process)

  24. E-Biz/IT Organization Functions • Applications Development – By Line of Business (LOB) – Lead the insertion of new and changing applications and maintain the stability of the software (only) throughout the life of the product. • New Technology – Research and Planning – Evaluate and recommend new technologies, and develop technical standards and guidelines that support the company’s mission and business objectives. • Business Consulting – Actively markets and sells the services that the IT organization believes it provides as a competitive advantage for the business. • Enterprise Services (Data Center)– Build and maintain the stability of the environment that supports new and changing applications and the exchange of information in the enterprise.

  25. E-Biz Leadership

  26. Problems and Issues • Fragmentation – Separate technology groups within the same basic function. • Under-Developed Process Infrastructure – No formal recognition, responsibility, and ownership exists for core production processes (technical and administrative processes). • Operations Functions in Non-Operations Group – A non-operational group (i.e. application development) are managing operational functions.

  27. Shared vs. Distributed Computing • Architect and Distribute – Concept by which E-Biz/IT departments were to drive technology and standards and then stand back and let the frontline business units develop and manage their own custom development and support of systems in a self-dedicated manner. • Development and Support - Today the trend has swung back to a more centralized model of development and support.

  28. Team Leader Responsibilities • Project Initiation and Purpose Statement • Communications – Keep all constituencies well informed. • Change Management – Develop and implement a process to manage changes to the project plan and work schedule. • Conflict Resolution and Ground Rules – Make sure the team addresses conflict. • Risk Management and Contingency Enactment – Make decision required to enact contingencies.

  29. Design and Planning • Design – Encompasses two equally important activities: • Evaluating and choosing the system management software to support the technology architecture components. • Defining or refining the administrative processes and choosing the technology to support them. • Planning – Development of the project plan, which may overlap with design but cannot be finished until the design is complete.

  30. System Management Software

  31. Technical Architecture Design

  32. Design and Planning Considerations • Platform Architecture – Supportability and cost are important. Supportability in this context refers to skill set investment. • Budget – The cost estimates received in the responses to the RFP will be used to help develop the final budget. • Timeline – For purposes of evaluating RFP responses, timing issues include items such as budget cycles, execution of related projects, the pressure to upgrade related technology to increase space, scalability, etc.

  33. Outsource vs. Insource • Analyze the cost effectiveness of outsourcing. • Decide what to outsource, when to outsource, and how to manage outsourcing. • Automation projects offer three general opportunities for outsourcing consideration: • Product • Implementation • Ongoing Service

  34. System Management Software: Build vs. Buy • Automation of technical architecture components will require a decision regarding the use of third-party software products vs. building the functionality in-house. • Options include: • Purchase a third-party software product and use it “as is.” • Purchase a third-party software product and have it customized. • Build the functionality yourself. • Buy – “Off the shelf” products are preferable to re-creating the wheel. For example, in the area of office automation, why would any company attempt to develop its own suite to replace the functionality that Microsoft Office provides? • Build – The decision to build will depend on the size and complexity of your initiative, your functional requirements, and your budget. Two types of system management tools exist: 1) Specific performance and capacity utilities 2) full-blown enterprise management tools. You typically have no reason to consider building enterprise-sized products as the requirement set is too large. The most attractive option you will have for building your own system management tool will be in specific performance and capacity utilities (e.g., Disk Capacity Management).

  35. Process Architecture Design

  36. Production Acceptance • Definition – Process that identifies the operational requirements to implement and manage new and changing applications. • Objective – To establish and maintain a process to identify the operational requirements to deploy and provide ongoing support to new distributed applications in the production environment. • Process – The Production Acceptance process is initiated by a Project Lead. A team is made up of representatives from NW Operations, Systems and Database Management, Help Desk, Computer Operations, and Production Control. The process incorporates periodic team meetings that present, track, and close out the following: a) New IS initiatives being introduced and b) Progress on initiatives in process.

  37. Production Acceptance

  38. Problem Management • Definition – A centralized process to manage and resolve user network, application, and system problems. • Objective – Track and resolve problems expediently using a disciplined problem management system, including tools, and guidelines in order to: • Establish an ongoing process of resolving problems • Minimize their impact on IT services • Optimize the time and effort spent in problem solving

  39. Problem Management Process

  40. Change Management • Definition – A process that coordinates all changes that affect the production environment. • Objective – To establish and maintain a process for the review, documentation, and authorization of changes to the computing system prior to implementation. And to control the impact of “required” changes, reducing problems, and improving the probability of achieving reliable, available, and serviceable-disciplined computing objectives, including: • Application changes • Data file changes • Hardware upgrades • Operating systems and middleware changes • Bug fixes • New applications affecting dependencies

  41. Change Management Process

  42. Asset Management • Definition – Process to query, discover, track, and store enterprise computing resources, including hardware, operating systems, and applications. • Objective – To establish and maintain a process that ensures the effective and accurate input, update, retrievability, and auditability of IT computing resources. And to establish an end-of-life process to systematically identify assets that have aged off the books and are no longer useful to the enterprise and to cycle them out of the environment.

  43. Disaster Recovery • Definition – Process to enable recovery in the event that a disaster should render mission-critical systems inoperable. • Objective – To establish a plan and practice a process for recovering mission-critical applications based on business risk and priorities. • Process – The plan is based on the concept of the Production Recovery Facility (PRF), containing all the hardware and network connections required to function as a data center. The plan assumes that procedures for regular tape backup are in place. At recovery time, the designated servers in the PRF will be booted and restored from the backup tapes of the primary servers.

  44. Planning • Tasks – Steps required to deliver the milestone. • Timeline – Deadlines associated with tasks and milestones. • Dependencies – Sequencing and relationship between milestones and tasks. • Risks and Contingencies – Identification of risks and mitigating factors. • Resource Allocations – Staff requirements and time required to complete tasks. • Budget – Cost of the project, including staffing, product purchasing, deployment, administration, etc.

  45. Financial Planning • Executive Summary • Capital Expenditures • Operational Expenses • Assumptions: • Hardware – Lease or Purchase • Software Purchase and/or Develop • Ongoing Service • Cost Benefit Analysis

  46. Lease versus Buy • Company-Cultural Decision – Accounting rules and the way your company has adopted them are likely to dictate the lease versus buy decision. • Benefits – a) Low initial cash layout, b) Ability to finance service costs, and c) Upgrade path to future hardware. • Fair Market But-Out – Option to either purchase the hardware at the determined fair market value or allow you to give it back. • Lease to Own – Provides for ownership at the end of the term.

More Related