Better Resource Utilization - Using Business Applications?

In an earlier post, I had outlined an idea to improve the usability of enterprise systems by creating a unified task dashboard. By having one dashboard for all activities, which could span multiple applications, users/resources can get a holistic view.

In this post, I want to extend this idea and would like to propose to the software companies/product manager’s work on expanding the capabilities of their tasks/work flows and start looking into unified resource utilization!

The first step would be to capture business process execution with accurate tasks within workflows. The second step would be to accurately estimate the time required to perform the tasks.

If and when we can track all tasks across all applications, we should be able to generate data, reports and metrics on resource utilization and be able to estimate current and future work loads accurately and be able to assign the right resources to the right problem and thus improve effectiveness and efficiency of the organization.

"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"

Unified Task Dashboard! Utopia?

In an earlier post, I had listed a number of emerging or new TLA's (three letter acronyms) in the enterprise application space like ERP, PLM, PDM, CRM, SCM, SRM, BPM etc...As the usage of these of applications and technologies mature within different organizations, users will soon have a set of task dashboards which outline the tasks they have been assigned within each of these applications and when it is due.

this begs the question, if we can integrate applications and have strategies like data integration / master data integration why cant we integrate the applications and create a unified task dashboard?

Most of the integrated software vendors could provide this capability but companies which have chosen best of breed applications will struggle with this unless they learn to federate and build services which can kick off / complete tasks and seamlessly integrate the applications and provide their users with one interface.

This could impact user adoption and greatly increase speed to proficiency of users and is rarely considered during software selection, planning and implementation!

"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"

Primer to ERP

Enterprise resource planning (ERP) is a company-wide computer software system used to manage and coordinate all the resources, information, and functions of a business from shared data stores.

The origins of ERP lie with MRP systems which was primarily focused on production planning, inventory control and manufacturing processes. Over the last 20 years, the industry has matured and adopted a number of best practices and has significantly increased the scope and functionality offered. Today the higher end ERP systems offer an integrated package or a suite of functionality which includes Product lifecycle management, Supply chain management (e.g. Purchasing, Manufacturing and Distribution), Warehouse Management, Customer Relationship Management (CRM), Sales Order Processing, Online Sales, Financials, Human Resources, and Decision Support System.

In a number of companies, ERP systems form the backbone of the IT application infrastructure. In terms of architecture most ERP systems have 3 tiers, a presentation layer, a business logic layer and a database layer. Some of the software vendors offer a number of options for the presentation layer like windows based GUI or a web based interface. In terms of business logic or application layer, proprietary code is used in addition to some common standards. Programming might have to be done in the proprietary language…recently most of the vendors have embraced J2EE standards and allow programmers access to their APIs to enhance capabilities.


Some of the benefits of ERP systems include
(1) real time information for all functional areas of the enterprise
(2) data standardization and accuracy
(3) best practices and one location for all business process execution
(4) analysis and reporting to support strategic planning

Popular ERP Vendors
• Microsoft Dynamics
• Oracle e-Business Suite
• SAGE
• SAP Business One
• Infor Global Solutions
• NetERP from NetSuite
• Lawson Software
Overall revenue of the ERP software market is in excess of $21.4 billion worldwide. This is a huge space, with a lot of consolidation occurring. As SaaS adoption grows, hosted solutions are becoming increasing competitive and look very attractive to CIO’s under pressure to reduce costs.
This is a mature space and a number of software providers offer a wide portfolio of capabilities which encompass the whole enterprise including
(1) financials (general ledger, accounts payable, accounts receivable, cost accounting, project accounting, fixed assets…)
(2) human resources (workforce management, payroll, benefits, personnel management, training)
(3) sales management
(4) quality management
(5) Supply chain management
(6) Manufacturing management (product costing, shop floor control, production planning…)
(7) Quality management
(8) Field service and repairs

In addition, most of the ERP software vendors have invested heavily into technologies/modules to support PLM, CRM, and Portals to increase their footprint within customers by offering integrated solutions.

"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"

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"

Convert Failures into Success!

I recently came across an article from CIO.com , on why IT projects fail.

It had some data on a study conducted in 2007 study by Dynamic Markets Limited of 800 IT managers across eight countries which showed that:
• 62 percent of organizations experienced IT projects that failed to meet their schedules
• 49 percent suffered budget overruns
• 47 percent had higher-than-expected maintenance costs, and
• 41 percent failed to deliver the expected business value and ROI

This got me thinking about the failure rates…in my opinion these numbers are on the low side. After all, no one wants to admit they were late or did a poor job on key company wide initiatives…

If you are trying to implement a new system, how should you go about it?

I would start with assessing

(1) Drivers for change: why do we need to change our current modus operandi for executing business process? Is there a clear advantage of the new system? Is it going to add value? Are we at risk due to obsolescence of existing platform(s)

(2) Are we ready for change? Even if the new system is the right thing to do, are we ready for change? Do we have the resources required to plan, define, test and implement this new system in addition to taking of care of day to day business? Do we have the discipline to adhere to the rules and logic built within this new system or are we going to modify it so that we can continue with business as usual but in a new locale? Is this a key initiative? If so is executive management aligned with requirements, costs and possible impact on performance?

(3) Do we really understand our current business processes and systems? In most cases, it is easy to blame the instrument (business solutions) and not the musician. If you truly understand your business process and can clearly identify the flow of information, material and finance at each and every step of your end to end processes, then proceed with scoping, feasibility, selection and vendor assessments. If you understand your system (process and business solutions), then in some cases, you may not need a new tool, you can super charge your existing toolset and reap the same benefits.

(4) Software selection, my approach would be is establish a budget based on fund availability. Then benchmark with companies within your space and similar sized companies not in your space. Analyze their success and failure stories, gather as much information as possible on how much they spent and on what. Get information on what vendors they reviewed and why they selected a particular vendor. Now that you are armed, create a check list of must have capabilities to support business process! Don’t focus on technology rather focus on capabilities to bring about success by implementing a new business solution. Be

(5) Implementation, ensure that your change is well socialized and aligned to at all levels, use best practices in IT change management, project management and run the implementation as you would run your business. Focus on your customers and ensure that their success is an integral theme of your implementation. Ensure you test well and properly to ensure that all your processes will execute well within the new system. Establish a super user community ahead of time and implement a “train the trainer” program. This will ensure that your support group doesn’t get overwhelmed upon go-live.

These points are general guidelines, over the next few weeks I will add more details on best practices for each of the bullets.

"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"

Architect!

Over the last few years, there has been an increased focus on architecture within the IT domain. If you spend some time searching for people with “architect” in their title, you will find a multitude of titles like

(1) Enterprise architect

(2) Data architect

(3) Business process architect

(4) Application architect

(5) Solution architect

(6) Infrastructure architect

(7) Security architect

(8) Technology architect

Are all of these roles the same? Or are they complimentary?

I like the description posted on Wikipedia for the function/responsibility of different architects.

“Enterprise architects are like city planners, providing the roadmaps and regulations that a city uses to manage its growth and provide services to its citizens. In this analogy, it is possible to differentiate the role of the system architect, who plans one or more buildings; software architects, who are responsible for something analogous to the HVAC (Heating, Ventilation and Air Conditioning) within the building; network architects, who are responsible for something like the plumbing within the building, and the water and sewer infrastructure between buildings or parts of a city. The enterprise architect however, like a city planner, both frames the city-wide design, and choreographs other activities into the larger plan.”

These roles are different and serve different purposes. The roles are complimentary and the functions. In order to implement business systems and underlying infrastructure, specific architecture domains to be covered (Business, Data, Applications, Technology).

The key to success is engaging all the different facets of architecture to create a technology roadmap and strategy by which your organization can start from the current state and finish in the end state so as to achieve corporate objectives and goals.

"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"

Data Migration: Challenges & Joy! Part 2.

Forewarned is forearmed

Before we jump into details about migration methodologies, let us step back and understand some of challenges ahead of us. Whether you are migrating from a legacy system or a spreadsheet/database, you have to understand everything about your “SOURCE” system.

Common misconceptions about migration

• Data migration is an IT job function.
• We know our data!
• Data migration is one of the last steps taken before you go live with the new system.
• We can always change it after we go live.
• Acquiring legacy data is easy.
• Existing data will fit the new system.
• Existing data is of good quality.
• Existing data and business processes are understood.
• Documentation exists on data rules and formatting.
• We Don’t Need Tools or Special Skills
• Migration Is a Separate Activity

What you as the lead of the migration effort need to do is work with your team to dismiss these misconceptions.

Data migration is not a matter of copying data! In order to be successful at migrating data, one has to thoroughly understand
(1) Why is the data being migrated, significance and value to the organization?
(2) What data is being migrated?
(3) Where does the data reside currently?
(4) What are the rules for the data in the “Source” system and how is the target system setup?
(5) Who are the experts for each of the data domains?
(Hint: do not limit yourself to an IT resource)
(6) What is the success rate of migrating into this application?
(7) Who else in your industry segment has been through this activity?
(Hint: Do a benchmark)
(8) What do you need from a hardware/software perspective to support the data migration?
(Hint: Benchmarking and reference calls will provide this information)

Now that you armed with some answers which will highlight what you need to focus on, we can step back and think through our methodology.

Don't lose your humor, remember your mantra “I love data migration”

"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"

Data Migration: Challenges & Joy!

What is data migration?

Data migration is the process of transferring data between storage types, formats, or computer systems.

Over the last decade, I have led multiple data migration efforts and found each one of these projects challenging and enriching. I keep swearing that I will not take up another but yet I always do. In a series of posts, I am going to share my experiences so that you may benefit from my lessons learnt and insights.

Common Data Migration Scenarios: when would you have a need to migrate data and create a project around this activity?
1. Mergers and acquisitions
2. Legacy system modernization
3. Enterprise application consolidation, implementation, or upgrade, such as an SAP ERP or CRM implementation
4. Master data management implementation
5. Business process outsourcing

Why are Data Migration Projects Are Risky: If you have been assigned as the lead for data migration, be aware of the heavy odds against you! Do your research and do it well.
Based on reference documents I have researched over the years (Gartner, Standish Group Study), I have found that
1. 84 percent of data migration projects fail to meet expectations
2. 37 percent experience budget overruns
3. 67 percent are not delivered on time

Why Data Migration Projects Fail: In earlier posts, I have outlined the importance of data management and the pitfalls of bad data management. These contribute to the overall success/failure of large implementation (and its data migration). Here are some reasons that have been attributed to failures of data migration.

1. Lack of methodology
2. Unrealistic scope
3. Improper understanding and use of tools
4. Inattention to data quality
5. Lack of experience

While data migration is essential to the success of implementation of a new application or business system, its role in the project often overlooked and underestimated. The common assumption is that tools exist to extract and move the data into the target application, or that data migration is something a consulting partner will handle. Often project teams tasked with data migration focus solely on the timely conversion and movement of data between systems. But data migration is not just about moving the data into the new application; it’s about making the data work once within the new application. This means that the data in the new application must be accurate and trustworthy for business users to readily transition from their legacy applications to adopt this new application.

In upcoming posts, I will outline the methodology I have used and why I have chosen this approach. Most of my team members would fondly remember my mantras of “Wash, Rinse & Repeat” and “I love data migration”. :)

"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"

Zachman Framework: My Experience

As a rule of thumb, when I approached for business process improvements or systems development request, I ask the 6 W questions (What, How, Where, Who, When and Why). As I got better with this methodology, I came across SDLC best practices and finally found the Zachman framework.

What is the framework?

The Zachman Framework is a comprehensive, logical structure for descriptive representations (i.e., models) of any complex objects. It is neutral with regard to specific processes or tools used for producing the descriptions. The Framework, as applied to enterprises, is helpful for sorting out complicated technology and methodology choices and issues that are significant to general and technology management and identifying the kinds of models for a given project.

The Zachman Framework provides a common context for understanding a complex structure. The Framework enables communication among the various participants involved in developing or changing the structure. Architecture is the glue that holds the structure together. The Framework defines sets of architectures that contain the development pieces of the structure.

The Zachman framework gathers and refines principles from older methods. It has a structure (or framework) independent of the tools and methods used in any particular IT business. The framework defines how perspectives are related according to certain rules or abstractions. A framework takes the form of a 36-cell table with six rows (scope, business model, system model, technology model, components, and working system) and six columns (who, what, when, where, why, and how) as shown in the figure below.



The rows of the Zachman Framework define the various perspectives of the enterprise and the various roles in the enterprise using that information.
1. Scope (Contextual/Planner view): Definition of the enterprise’s direction and business purpose. It includes enterprise’s vision, mission, boundaries and constraints. Usually these are textual artifacts/definitions providing the context for each column for e.g. the “Why” column cell will contain the business goals, performance measures for each function. The “What” would contain the various high level data classes required etc. The idea here is to identify the requirements and the external drivers affecting the enterprise and perform business function modeling.
2. Enterprise Model (Conceptual/Owner’s view): At this level more focus is towards the business and the associated processes. At each column level information is gathered with the business processes in perspective. For e.g. to answer “Why” you will define the policies and procedure for the processes, the “How” would be the Business process definition itself, the “Who” would be the roles and responsibilities for each of these processes.
3. System Model (Logical/Designer’s view): This defines the business described row 2, but in more details. At this level the logical models are defined for each row cell. For e.g. A logical data model is created to identify the data flow for achieving the business data requirements specified in row 2. Similarly logical network models are created to understand the network setup required.
4. Technology model (Builder’s view): This describes how technology may be used to address the high level needs identified in the previous rows. Various technology related decision like decision for the DBMS type to use, the network elements required, and the access privileges for the users etc. are identified.
5. Detailed Model (Sub Contractor view): As we can understand at this level its is the deployment phase where the details are low level like database specifications constrained as per the physical models, network configuration, detailed user privileges and so forth produced.
6. Functioning system (User’s View) : Here the final implementation of the various systems is depicted and its impact to the users is mapped. Information like what data is being entered by users and getting stored in the database or the actual message flow happening over the deployed network and so forth is considered at this stage. The idea is to use this information for operations management, evaluation of the systems deployed etc.

I have spent some time reading about the weakness of this framework (for e.g. process/documentation heavy, little or no acceptance from development community), but I favor a business process centric approach. In my mind, all development activities should have a business value and justification. One way to clearly ensure that all stakeholders and departments understand the overall development program is through a visual display of the interactions of process, systems, data and business rules.

"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"