Showing posts with label ITIL. Show all posts
Showing posts with label ITIL. Show all posts

Best of Breed vs. Integrated Systems

You have probably had to make this decision several times in your professional and personal lives…for example a vacation plan where you have to decide if you want to create your own itinerary and define the trails that would provide you with maximum comfort or adventure (whatever floats your boat) or be part of an overall tour targeted at a group of people who have varied interests…
The decision needs to be based on what each package offers you, cost benefit, return on investment, future value/costs etc.
For most of the processes used within the enterprise, a number of software solutions exist. If you are in the market for a software solution to address current problems / revamp existing application framework or implement a solution based on future requirements you will have to make this decision!
Integrated systems provide multiple applications with a common architecture and consistent user interface so that all modules/functionality have a familiar look and feel. The downside is that some applications may not have the maturity or capability to address all functional areas, causing users in these areas to become disgruntled or slow down adoption.
Best of breed systems, designed specifically to address processes and common problems in certain functional areas, generally provide the maximum functionality to a set of business process. They pose challenges, such as increased training and support, complex integrations with other systems, possible duplicate data entry / redundant data.
There a number of factors to be considered if you want to thoroughly assess the differences between “best of breed” and integrated systems. These factors are
(1) Implementation Cost
a. Software cost / licenses
b. Integration
c. Customization
d. Hardware
e. Resources
f. Consulting
(2) Implementation timeline
(3) Value to business
(4) Return on investment and Payback period
(5) Fit / Adaptability to company specific business processes
(6) Quality
(7) Maturity
(8) Vendor capability and lifecycle
(9) User
(10) Future Support costs
a. Need for additional hardware
b. Software maintenance fees
c. Need for additional headcount
“Best of breed” applications typically have a shorter implementation cycle with an accelerated payback period. I have seen numbers like 6-12 month implementation time as opposed to 18-24 month for integrated systems…12 month payback for best of breed as opposed to 2-4 years for integrated systems.
In summary, the decision needs to be based on business needs and constraints placed by budget and resource availability. Be mindful that each system has its own benefits and shortcomings and plan accordingly.

"Disclaimer: The views and opinions expressed here are my own only and in no way represent the views, positions or opinions - expressed or implied - of my employer (present and past) "
"Please post your comments - Swati Ranganathan"

How many applications do you need to run your business?

Over the last 10+ years, a number of acronyms have popped up in the enterprise application space. Traditionally most companies started out with in an ERP system and depending upon their business added additional applications to support the business.
What is ERP?
ERP stands for Enterprise Resource Planning. ERP is a way to integrate the data and processes of an organization into one single system. This seems to be the commonly accepted definition of ERP systems, if that is true then why do we need so many other applications?
I am going to post a series of blogs on the different applications and describe their roles, capabilities, maturity and why the need for them appeared and who the “big players” of these markets are.
In this post, I am going to list out the applications seen in the landscape and briefly describe their function.
Some of the applications that you would see in the IT landscape are
• CAD (Computer aided design) to support modeling of hardware and electrical/electronics
• PDM (Product data management) systems to support data management
• PLM (Product lifecycle management) systems to support workflow, engineering change, bill of material management, release to manufacturing etc.
• MES (Manufacturing execution systems) to manage work in progress on the manufacturing floor
• CRM (Customer relationship management) systems manage, track and organize its data / contacts with its current and prospective customers
• BPM (Business process management) systems provide process management capability with workflows
• SCM (Supply chain management) systems provide the ability to manage the entire supply chain and support planning, sourcing, manufacturing, delivery and return logistics.
• KM (Knowledge management) to support knowledge sharing of best practices and lessons learned.
• SRM (Supplier relationship management) to support managing vendor relations and lifecycle.
• PPM (Project Portfolio Management) systems used for analyzing and collectively managing a group of current or proposed projects.
• BI (Business intelligence) systems help the business acquire a better understanding of its commercial context.
• EMM (Enterprise Marketing Management) systems manage marketing’s end-to-end internal processes including Web Analytics, Campaign Management, Digital Asset Management, Web Content Management, Marketing Resource Management, Marketing Dashboards, Lead Management, Event-driven Marketing, Predictive Modeling etc.
• HRMS (Human resource management system) or HRIS (Human resource information system) manage all processes within human resources.
Though this list is long, this list is not complete. Depending upon the industry many other applications exists for e.g. LIMS (Laboratory Information Management System) is important to healthcare, drug and the food industry…In addition, almost all companies have a suite of internal applications to manage issue tracking and resolution, portals to share information with their customers, suppliers and different organizations…
Now if you step back and wonder why so many systems exist, and perform a root cause analysis the usual culprit is lack of capability to support all facets of the business within one application resulting implementation of best of breed / internal applications as opposed to one integrated systems.
In later posts, I will describe the factors driving “best of breed” Vs integrated systems.
With all these different applications, IT organizations are challenged with (1) integration and seamless of flow of information (2) managing application portfolio and associated costs (3) managing platform obsolescence and ensuring that the whole application portfolio is on the current/latest release levels. These challenges would make an interesting post as well :)

"Disclaimer: The views and opinions expressed here are my own only and in no way represent the views, positions or opinions - expressed or implied - of my employer (present and past) "
"Please post your comments - Swati Ranganathan"

IT change management part 1

Change management within IT has gained a lot of traction in the last 5-10 years, in some cases this has been accelerated by the need to comply with SOX regulations and wider acceptance of ITIL concepts and best practices.

In order to help the business meet rapid changes, IT needs to react quickly and without impacting the quality and stability of the environment and the service levels. Changes to IT systems are required due to a number of reasons, some of which are related to
1. Application
2. Hardware
3. Software
4. Network

For e.g. if you have to upgrade your business systems / business applications to the next release or upgrade / change hardware like CPU, RAM or other peripherals, or if you have to make changes to software like operating systems due to new patches or fixes or changes to your network infrastructure.

Change management as evolved from an ad-hoc basis into almost a science with specific goals, metrics, risk management and methodology.

The goal of change management from a business perspective is to ensure

• All authorized changes are based on business needs and are approved
• All changes requests are addressed and implemented in a efficient and conforming manner
• Business risk is managed and minimized
• Standardized methods and procedures are used for handling of all changes
• All changes to the IT infrastructure (software, hardware, applications and network) are recorded and documented

Now you might wonder, why I wrote from a business perspective…the changes should be based on good business reasons, it should be tied with a business approved initiative or have a valid reason such as potential adverse impact to the business. If you have to install a patch and explain the need for this change to a business person they may or may not understand the reasons. If you put it in the context or risk or benefit to their operations (possible impact of downtime to their applications / users), they will become interested very quickly.

How do you go about implementing a change management methodology within IT?

First define your process /policy clearly define
• Scope (which some or all pieces of IT infrastructure should follow this process).
• Roles, responsibilities and procedures related to change management
• Define best practices for change management and configuration of software
• Review frequency of your policies, procedures and standards
• Key performance indicators which indicate your service level and operating level performances.

All business critical applications should be under change control and best practices defined for change management should be adhered to. Without having a proper change control mechanism in place, business could be impacted by poor or no risk assessments and unauthorized changes could occur.

Roles and responsibilities related to change control are essential to ensure proper implementation. There needs to be a distinction between developer, tester or approver and implementer of changes. This can be complicated further, if you have multiple environment such as development, QA and production. Change control is not easy thing to accomplish as it involves participation and adoption of all stakeholders within IT. In some cases, smaller organizations may not be able to assign different people to different roles.

Standard operating procedures must be developed based on industry and software/vendor best practices. For example, changes to codebase of business systems must be stored within a code versioning system. Configuration management of all business systems and operating systems should be considered. There are a number of solutions which can address this. At a minimum, consider a spreadsheet based solution which highlights changes and what files/directories were impacted and tie these to change requests and package updates.

As roles and responsibilities change from a function perspective, change control processes and procedures should be updated to indicate the current state. In addition, based on lessons learned, changes to documentation might be necessary. Setup a reoccurring meeting to discuss policies and procedures on a frequent basis, maybe start out with once a quarter.

KPI’s should highlight ability of IT to react to the business and how quickly the changes were impacted and should also include adverse impact to the business through downtime, missing functionality etc in terms of dollars and hours. Review these KPI’s with the business on a frequent basis and work on areas where improvement is required.

"Disclaimer: The views and opinions expressed here are my own only and in no way represent the views, positions or opinions - expressed or implied - of my employer (present and past) "
"Please post your comments - Swati Ranganathan"