Minggu, 17 Januari 2016

Summary Session 17-18

Organizational Change and Business Process Reengineering (Session 17-18)


Organizational Project Management Maturity Model (OPM3)
          Seeking to create a framework within which organizations can re-examine their pursuit of strategic objectives via Best Practices in organizational project management
          The OPM3 model is a three-step continuous improvement process.
        Step 1: Knowledge
        Step 2: Assessment
        Step 3: Improvement

Benefits of OPM3
          Helps organizations identify and deliver the right projects to advance their strategy.
          Improved project performance and return on investment - Isolates process improvements while forcing organizations to consider external pressures increasing operational and organizational efficiency
          Helps the organization align its strategy with the projects that sustain business success
          Mitigates operating costs by keeping projects aligned to business strategy

BPR Methodology
          Preparation—Set goals and vision, identify teams, and develop an inventory of processes that need to be evaluated.
          Define the “as is” process and evaluate cross-organizational issues.
          Map out “to be” processes based on best practices (i.e., related to ERP).
          Test and measure new processes based on meeting goals and vision.
          Re-evaluation—revise, adjust to improve processes.
          Preparation-Drivers behind the need for BPR:
          Implementing a current purchased ERP system
          Automating current manual or error prone processes
          Improving service to customers
          Streamlining current processes to decrease time to market
          Participating in or conducting e-Marketplaces
          Reducing costs
          Addressing accountability
          Conducting e-Procurement
          “As Is”
          Working with the vision and goals, the functional teams must define the existing processes.
          Need both a written description and graphical depiction of each and every process.
          “To Be”
          This phase addresses timing of processes and the changes needed to meet the original set of goals.
          Testing and Measurement
          The testing and validation of each process is necessary to ensure that a step was not missed or that a process was not achievable.

Business Process Management
          BPM can be defined as:
        “A management discipline that treats processes as assets that directly contribute to enterprise performance by driving operational excellence and business process agility”
        BPM employs methods, policies, metrics, management practices and software tools to continuously optimize the organization processes to improve business performance against goals and objectives

Difference between BPR and BPM















 Best Practices of BPM
          BPM systems help managers in understanding the working of the business processes better so as to manage them more efficiently
          Successful BPM implementation requires separating the following:
        Human Intensive Processes - These processes are also known as “knowledge work.” They depend on people to do the work.
        System Intensive Processes - These processes involve a large number of automated transactions each day that do not require human judgment

Benefits of Implementing BPM
          BPM software aids in facilitating communication and synchronization resulting in high productivity.
          The employees become more efficient, because the workflow bottlenecks are removed using BPM software and thereby reducing the idle time of the employees.
          BPM software helps companies to cut costs.
          Employees feel better to work in an organized business processes architecture that was created using BPMS.
          Improved workflow results in better-quality products and services and thus makes customers happy.

Major Features of BPM
          Process modeling and simulation—Users can use the software to design processes that need automation.
          Systems integration—BPM software lets other information systems like ERP to be connected to the processes, and hence information can flow between the systems.
          User interaction and collaboration—BPMS has Web forms and other user interfaces to help the user to enter inputs and make other changes to the process.
          Process execution and monitoring—BPMS lets job to be routed through the process steps and sends notifications electronically and also tracks performance indicators of processes.

The Four Rs of Process
          Roles—establishing a set of defined user roles that will not change with employee absences or departures
          Relationships—identifying the interactions necessary to complete a process
          Rules—developing a fixed set of process steps that will be followed in most situations

          Routing—electronically transferring forms and documents for review, approval, and so on.

Summary Session 15-16

Program and Project Management (Session 15-16)

I've been both a project manager and a program manager.  There was a time I wasn't really sure what the difference was.  I am now comfortable with my answer, but I suspect there is not yet true consensus in the industry.
I asked my friendly search engine for the definition of program management and got back a wide range of answers, that have common themes, but seem loosely coupled at best.

Definitions of Program Management
I found these definitions on the Web.  Note:  Some of these sites may no longer be available.
·         Delivering a project or projects from concept through completion using a team of experts whose sole focus is obtaining the owner’s goals. Program management combines the ability and resources to define, plan, implement, and integrate every aspect of the comprehensive program.
·         Activities that include planning, monitoring, and reporting of ongoing activities, cost/schedule tracking, clerical, other administrative support, and grants to states and localities.
Formerly available on a US Dept of Energy site that is no longer available. 
·         The process whereby a single leader exercises centralized authority and responsibility for planning, organizing, staffing, controlling, and leading the combined efforts of participating/assigned civilian and military personnel and organizations, for the management of a specific defense acquisition program or programs, throughout the system life cycle.
·         The coordinated management of a portfolio of projects to achieve a set of business objectives is called program management. Or, a program might refer to an ongoing set of activities internal to the organization, for example, a Total Quality Management program, workplace safety program, supplier development program, etc.
·         Understands how programs are designed to use appropriate service strategies to meet program goals. Understands how budgets are developed and costs are tracked for individual programs. Is able to use indicators and established instruments to document program performance and outcomes.
·         Program management is the process of managing multiple on going projects. An example would be that of designing, manufacturing and providing support infrastructure for an automobile make. This requires hundreds, or even thousands, of separate projects. In an organization or Enterprise, Program Management also reflects the emphasis on coordinating and prioritizing resources across projects, departments, and entities to insure that resource contention is managed from a global focus.
 
The International Association of Project and Program Management defines both program and project management. 
·         Program Management:  Program management is the active process of managing multiple global workstreams or projects which need to meet or exceed business goals according to a pre-determined methodology or life-cycle. Program management focuses on tighter integration, closely knit communications and more control over program resources and priorities.
·         Project Management:  Project management is the centralized management by an individual to plan, organize, control and deploy key milestones, deliverables and resources from conception through retirement, according to customer goals. Often project managers are skilled to use specific templates and techniques to manage through the preferred project life-cycle.

The common threads in these definitions include:
  • Multiple Projects:  A program consists of a series of related and possibly interdependent projects that meet an overarching objective.
  • Planning:  Any program or project requires planning.   A project has its own schedule, its own milestones.  A program may entail coordination and between and scheduling of a subset of the projects that make up the program.
  • Monitoring:  Management must monitor progress, issues, and risks ... regardless of whether at the project level, or the program level.  Program management entails monitoring at a higher level.
  • Reporting:  As with monitoring, there must be reporting at both the project and the program level.  Program management consolidates the reports from component projects comprising the program for its reporting to higher level management.
  • Budget:  In some organizations, projects are responsible for their own budgets but often, the project manager is working against tasks and deadlines, with budgets that were set at higher levels.  Programs are more often, but not always, inclusive of budget management.
So, what are the differences between project management and program management?  I believe there are two key characteristic differences that distinguish program management from project management:
  1. Programs encompass a series of projects that in aggregate achieve an overarching set of objectives, where projects have specific and more singular objectives.  In this sense, the difference is driven by scope and scale.
  2. Program management involves more than oversight of a set of projects.  It includes application of common standards and processes to the execution of projects.
I have also worked for an organization that chartered the Program Management Office (PMO) to report to technology, with responsibility for process definition for the software development organization.  This didn't work well, as processes must extend beyond the technology organization, and should not be dictated by technology to business units. That said, Program Management should work to support and enforce process adherence across all organizations of the business.  If Program Management is to be charged with overall process definition and / or improvement, the PMO should not be reporting exclusively into Technology. 
Program Management extends beyond technology practices. Program Management includes:
  • Oversight of related projects.
  • Establishment of business and technical processes.
  • Audit and enforcement of established processes.
  • Acceptance, analysis, and implementation of process improvements.
  • Measurement of existing processes against established metrics.
Project Management, on the other hand, focuses on a deliverable within the framework of established project management processes as established by the Program Management office (PMO).  This is true, whether the project is a business or a technical project, and whether the project is related to one or more other projects, or is a stand-alone project.
In summary, Program Management addresses the management of project management, setting up processes, monitoring and measuring project results, and coordinating related projects.


Summary Session 13-14

Operation and Post-Implementaion (Session 13-14)


What?
A Post-Implementation Review (PIR) is an assessment and review of the completed working solution. It will be performed after a period of live running, some time after the project is completed.

Why?
There are three purposes for a Post-Implementation Review:
  • To ascertain the degree of success from the project, in particular, the extent to which it met its objectives, delivered planned levels of benefit, and addressed the specific requirements as originally defined.
  • To examine the efficacy of all elements of the working business solution to see if further improvements can be made to optimise the benefit delivered.
  • To learn lessons from this project, lessons which can be used by the team members and by the organisation to improve future project work and solutions.
In some cases, the first of these objectives can be a contractual issue. Where that is the case, it may be safer to run separate reviews - one focused on contractual compliance and the other seeking to derive further benefit from a no-blame review.

When?
A Post-Implementation Review should be scheduled some time after the solution has been deployed. Typical periods range from 6 weeks to 6 months, depending on the type of solution and its environment.
The PIR is intended to be an assessment and review of the final working solution. There should have been at least one full processing and reporting cycle completed.
It should not be performed while the initial snags are still being dealt with or while users are still being trained, coached and generally getting used to its operation.






The PIR should be timed to allow the final improvements to be made in order to generate optimum benefit from the solution. There is no point in waiting too long as the results are intended to generate that final benefit for the organisation and team.

Who?
There is often a difference of opinion as to who should perform the Post-Implementation Review. Usually, members of the project team will want to complete the review as a natural extension of their responsibility to deliver optimum benefit from the solution. They understand what was required, what was changed, how it was achieved, how things are supposed to work, how to fix problems, etc.
There is a converse argument that the review should be performed by an independent team. This reduces the risk that any errors or omissions of the project team might equally be overlooked in their review.
A solution is to do both. An independent audit team, working in consultation with the business users and project team, could examine whether the results are satisfactory. The project team might then reconvene to consider that input and also to examine how to generate further value from the solution.

How?
A list of points should be drawn up to cover all elements of the operational solution. They should include such things as:


Current situation
  • Is the required functionality available?
  • Are the procedures properly documented, published and known about?
  • Have users received adequate training and coaching to take advantage of the new facilities?
  • Are staffing levels and skillsets appropriate for the actual workloads?
  • Are staff displaying appropriate attitudes to get the best out of the system (confidence in its capabilities, belief in its purpose, willingness to make it work, etc)?
  • How busy, usable, useful and adequate are support services such as the systems support function and help desk?
  • Are third parties such as customers and suppliers satisfied with the service?
  • Is the level and nature of identified faults acceptable?
  • Are faults handled at an acceptable speed and with satisfactory results?
  • Is data integrity being maintained within the system and in relation to other integrated or interfaced systems?
  • Are systems controls being applied correctly?
  • Are business, procedural and financial controls being applied correctly?
  • Does the system and its usage meet current legal and regulatory requirements?
  • Is the system able to process transactions at an adequate speed?
  • Does the system have the capacity to deal with the actual peak loadings as encountered and foreseen?
  • Are staff following operational procedures including backup, recovery, security and disaster recovery?
  • Has the project been properly demobilised, eg documentation filed, team members appraised and reassigned, equipment and facilities returned, final accounting and reporting completed, success and completion communicated?
Benefits
  • What were the final costs of the project?
  • What is the actual operating cost of the new solution?
  • What is the actual benefit being delivered by the new solution?
  • How does that compare to the original project definition?
Future improvements
  • Could further training or coaching improve the degree of benefit being generated?
  • Are there further functional improvements or changes that would deliver greater benefit?
  • Are specific improvements required in procedures, documentation, support, etc?

What learning points are there for future projects?
These questions will be investigated through a combination of investigative techniques including interviews, examination of documentation, performance statistics, hands-on tests and checks, etc. Implications and potential remedial options would then be assessed and evaluated. The findings and recommended actions would be prepared, normally in the form of a report or presentation.

Next Steps
The findings and recommendations will be presented to:
  • the solution's business owners,
  • the leading participants in the project, and
  • other parties who may be concerned with the results.
Specific actions should be proposed to address any further work that is recommended. This might be handled in several different ways, for example:
  • as routine support and maintenance,
  • as remedial work to be performed by the original project team,
  • for line management to address through user education and procedures etc,
  • as further phases of development involving new projects.



Summary Session 11-12

Software and Vendor Selection (Session 11-12)

Preview
-          Selection of a vendor that best meets the needs and long-term direction of the company is a critical first step in a successful implementation
-          In selecting a vendor, a well-understood selection process will need to be utilized
-          The company may want to hire a specialized consulting firm to assist in the selection process.
-          The steps involved in selecting a vendor generally are based on best fit of an ERP to business functions and the overall ERP vendor’s product performance in the market.

High Level ERP Purchase Process
1.      Vendor research and information gathering
2.      High-level vendor demonstrations and evaluation
3.      Needs and requirements assessment
4.      Development of request for bid or proposal
5.      Release request for bid to vendors
6.      Analysis and selection- Evaluation of bids, Functional evaluation, Technical evaluation, Vendor-detailed demonstrations, Contact references, Develop a total cost of ownership
7.      Vendor negotiation,
a.          Contract review and change,
b.         Pricing- software, maintenance, and consulting, support
8.      Purchase system

Vendor Research
-          First step is to identify a short list of vendors who will help to shape business requirements
-          Identifying and researching all aspects of a vendor package will assist companies in determining the total cost of ownership.
-          An exhaustive list of vendors is important for a successful implementation using current web search engines
What need to be consider during vendor selection:
-          Other businesses using the vendor
-          The vendor’s financial position
-          The vendor’s implementation philosophy and support issues
-          The hardware and software infrastructure used to support the ERP
-          The vendor’s direction and currency of software
-          The vendor’s release and upgrade strategies
-          The vendor’s user-base involvement in defining future functional changes
-          The vendor’s development and maintenance resources

Short List of ERP Vendors
-          SAP
-          Oracle/PeopleSoft
-          Lawson
-          SSA Global
-          Great Plains
-          Epicor
-          Infor Visual
-          Plex Online

Matching User Requirements to Features
-          Identification of user and system requirements can be done by documenting current legacy system functionality or by using business process re-engineering (BPR)
-          Two major documents are often a result: Data and functional flow of departmental & description of functions in each department and the level of importance of each function
Request for Bids (RFB)/Request for Proposals (RFP)
-          Expensive and time-consuming process for both company and vendor, but it can yield significant software savings when done right
-          RFB should include the type of ERP system the company wants (with specific functionality), specified hardware and software infrastructure, training requirements, and any specific contract issues (required by the company)

Vendor Analysis and Elimination
-          Office staff will need to evaluate functionality.
-          IT staff will evaluate the technology requirements.
-          Contract staff will need to evaluate the contract and pricing of the system.
-          No vendor will be able to meet all requirements so the company should focus on the best fit
-          Develop and analyze the total cost of ownership (TCO).

Contract Management and License Agreements
-          Talk should center on the products (including purchase, maintenance terms, and contract lifecycle management)
-          Services for implementation can be included or bid separately
-          Things every ERP contract should have: All deliverables clearly identified with delivery dates associated, ensure have acceptance authority as customer, and identify who has the authority to changes the contract
-          Quality manager/contract monitor responsible for making sure both sides abide by the terms and conditions of the contract
-          Changes should only be made when necessary due to unforeseen circumstances, mutually beneficial reasons, or unintended mistakes
-          Communicating progress keeps all involved and will also help to maintain momentum.

Implications for Management
-          Management must play a role in choosing the right system that will meet the company’s needs and requirents
-          Management must allocate enough time to evaluate the system, observe a complete and comprehensive demonstration, and communicate to references and others using the system.
-          Discussions with the vendor about future improvements and direction must be scheduled.
-          Negotiating with two vendors is time-consuming, but it will yield a better purchase price.


Summary Session 9-10

Implementation Strategies (Session 9-10)

Preview
In any ERP implementation strategies, we need to identify and plan all the implementation components

ERP Components
-       Hardware
An ERP system will require a powerful set of servers for development, testing, and production environment.
Key Resources
·         Servers: High-end multiprocessor systems, several gigabytes of main memory and several terabytes of secondary storage
·         Clients: People who use ERP systems (ex: end-users, IT support staff)
·         Peripherals: Such as print servers, printers, back-up power supply equipment, and networking hardware

-       Software
A set of operating instructions and logic called programs that control and direct the computer hardware to perform its functions.
Key Components
·         System Software: Operating system platform (ex: Microsoft Windows Server, Linux)
·         Database Management System (DBMS): Such as Oracle, Microsoft SQL
·         Application Software: Such as project management software, development software, remote access software

-       People Resources
·         End-users: Such as employees, clients, vendors, and others who will potentially use the system
·         IT specialist: Such as database administrators, IT operations support, developers, change management, trainers, and others in IT
·         The project manager: Puts together a harmonious team, works with top management in getting support and resource, and deliver the system and its benefit to the end-user

Virtualization
Virtual Machine (VM) server: technique to run multiple and isolated virtual servers on a single physical device, thus optimizing hardware usage. Two common models used for mission critical application are hardware virtualization and paravirtualization.
ERP Vendors and Virtualization
-          Microsoft: The two virtualization choices available are Microsoft virtual server and Microsoft virtual PC
-          Oracle: Same like Microsoft, Oracle VM uses paravirtualization architecture based on the Xen open-source technology that brings with it both Linux and Windows support
-          SAP: Providing tools, code tweaks, and support needed to ensure their SAP virtualization projects go smoothly
Benefits of virtualization
-          Enhanced hardware utilization allowing an organization to consolidate underutilized servers
-          Makes provisioning and deploying more agile
-          Through consolidation, virtualization can lower total cost of operations at the data center by the following:
·         Deferred purchase of new servers
·         Smaller data center footpring
·         Lower maintenance costs
·         Lower power, ventilation, cooling, rack, and cabling requirements
·         Lower disaster recovery costs
·         Reduced server deployment costs
-          Enhances business continuity and availability
Drawbacks of virtualization
-          Tendency to squeeze more performance out of a physical server by creating too many virtual machines leading to significant concerns when the server is operating at peak loads
-          Security problem: If a hacker compromises the security of the hypervisor, he or she might get access to all VM running on the host server

Third Party Products
Add-on software components either make system operate or add missing functionality
-          Integration with ERP
-          Strategic partners: Assist in addressing integration and interface issues with third party products
-          Middleware: Assist with the development of reporting databases that use extract translate and load tools
-          Support: Third party products support

Database Requirement
For an ERP system to perform up to expectations, the update or transactional component and the reporting component must respond in a timely fashion. Large ERP system implementations require robust relational database system (such as Oracle, DB2, Sybase, Microsoft SQL).
Selecting a relational database:
-          Availability of software applications
-          Availability of skilled, trained technical staff
-          Overall functionality of the database itself
Staffing and database administration: including the use of full time staff and consultants

ERP Approaches – Governance
Governance should outline and define committees and workgroups that are responsible for the different components of the implementation, their interaction and decision making.
Components:
-          Technical development
-          Hardware and software installation
-          Functional components
-          Communications and reporting
-          Change management
-          Project management
-          Project owners and sponsors
-          Budget management
-          Issue escalation process

Roles and Responsibilities
-          Owners (consisting of Senior Management): Determine overall policy, budget, and scope of the project
-          Project Executive: Oversees project activities, provides broad project oversight, resolves policy level issues, and ensures that the project stays within scope
-          Steering Committee: Oversee the project’s efforts and ensure appropriate leadership
-          Application Steward: Works with the other business owners to develop an overall business direction of the system, developing consensus, and resolving functional issues raised to the steering committee
-          Chairperson: Oversee the activities of the steering committee, ensuring that the committee functions in accordance with the overall project oversight. This includes budget, resources, deliverables, risk, and expectations management
-          Project Management Office (consist of the project executive, business and technical project manager, and the implementation partner.): Manage the day-to-day aspects of the project
-          Project Teams: Provide direction and ERP application knowledge with respect to business process design, configuration, conversion, testing, training, reporting, and implementation.
The following teams will exist:
·         Cross-functional component team
·         Functional component teams
·         Technical Infrastructure team
·         Development team
·         Change management team
·         Conversion team
·         Reporting team
-         Project Team Leads: Provide leadership and overall direction for the implementation, ensuring the quality of deliverables and adherence to the project plan and milestones. In addition, inform the project managers of any and all issues that are identified by their respective project team
-         Cross Functional Team: The integration team will consist of the module or project team leads from the business modules and the development leads. This group will meet as needed to discuss and resolve cross-module issues

Sample Set of Meetings
-         Project Sponsors Meeting
-         Steering Committee Meeting
-          Project Management Office Meeting
-         Module or Project Leads Meeting
-         Module or Project Team Status Meeting
-         Issues Meeting
-         Cross-Functional Module Meeting
-         Database Planning Meeting

Implementation Methodology
When a system implementation does not have a well-defined methodology, deadlines will likely be missed, budgets overspent, and the functionality may not meet the client’s requirements. ERP system implementations are very risky, but a well-defined project methodology will assist in managing those risks. The selected methodology should be able to address all components for the entire project including project start-up through system stabilization

Implementation Strategy
1.      Vanilla Implementation
When a company chooses not to modify or customize the system, but instead to change business practices to fit the system.
Reason to consider vanilla implementation.
-          Businesses with relatively straightforward business practices that are not unique
-          Businesses that are not skilled or experienced at building or changing systems
-          For a company using a purchased ERP system where the financial component is critical for reporting
-          All of a company’s branches are running the same system in a single instance, and entering and retrieving data in a similar fashion
-          For a competitive advantage, it is important to know the ability of what and where things are around the world with the business.

      Modifying an ERP
Businesses that have highly skilled IT developers and a proven process for managing modifications can choose to change the system to match their processes.
Benefits:
-          A single-system instance is easier to maintain and support.
-          Assessing organizational change along with modifying the system to meet the needs of the business will help to minimize risk.
Drawbacks:
-          If a system is modified, each modification will need to be analyzed in light of the upgrade to see if it needs to be incorporated in the upgrade or removed.
-          An upgrade can sometimes turn into a re-implementation, which requires more resources and time.

Platform Issues
-          Servers: As an infrastructure, it will need to grow as the system grows and expands with enough storage to ensure data is quickly retrievable
-          Network: Businesses need a reliable and secure network
-          Security: Several components must be installed and implemented to ensure that the system is secure from unauthorized access
-          Disaster Recovery and Business Continuity: Planning for a disaster and providing business continuity

Implications for Management
Successfully implemented ERP system, may create opportunities for a business to grow and change for the better. Decisions around the hardware, software, governance, methodology, and level of modifications need to be based on the goals set out for the purchase of the ERP system.
Two initial management decisions
-          Use of an implementation methodology
-          Whether or not to modify the system
Management must decide on whether or not to customize prior to the start of the implementation process and it must be communicated to all on the project.