Process Improvement Demystified

IT or BT? The debate is on!

2009-11-02T22:13:00.000-08:00

We have heard of IT, MIS and IS as acronyms to define the information management wing of every company, I just came across a debate to rename this to BT (Business Technology).

This is very interesting, at the core, IT or IS or even MIS describes the function they serve well. By renaming to BT the emphasis is clearly on engaging the business and ensuring that the business can succeed and has the tools to effectively leverage technology to improve efficiency, effectiveness, productivity and bring about change! (or transformation if you prefer).

I am in favor of this rename and new acronym (though we have too many already!)

Here's a link to the posting from CIO.com, Happy Reading!

Better Resource Utilization - Using Business Applications?

2009-10-31T23:47:00.000-07:00

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.

Profile data of migration leader

2009-10-30T22:32:00.000-07:00

What skills do you need to become a data migration leader?

If you have gone through my posts on this subject, you will be able to guess!

1. Strategic thinker with excellent analytical skills, able to balance strategy with tactical execution
2. Excellent understanding of business process (flow of information, physical parts/products and finance) and
3. Excellent understanding of technology (Databases (SQL, Oracle), Business applications (ERP, PLM, CRM etc.), programming,
4. Project management whiz

This might be a tall order but start working on each of these skills. Practice makes perfect.

Data Migration: A summary of my posts!

2009-10-30T22:07:00.000-07:00

Over the last 3+ months, I have outlined my thoughts on data migration. In order to be successful with large scale implementations of business systems like (ERP, PLM, CRM, BPM etc.), data migration is a key element.

Data migration is often ignored and not enough attention is paid to this portion of the overall project.

The methodology I have outlined in these posts can be applied to a number of projects including data consolidation, server consolidation, migration from one application to another and the list goes on.

The key is to pay attention to the business needs and to make them successful by taking care of the technology and project management issues!

Good Luck.

1. Data Migration: Challenges & Joy!
http://improveprocess.blogspot.com/2009/07/data-migration-challenges-joy.html

2. Data Migration: Challenges & Joy!
http://improveprocess.blogspot.com/2009/07/data-migration-challenges-joy-part-2.html

3. Rules For Successful Data Migration
http://improveprocess.blogspot.com/2009/07/rules-for-successful-data-migration.html

4. Phases of Data migration
http://improveprocess.blogspot.com/2009/07/phases-of-data-migration.html

5. Phases of Data migration
http://improveprocess.blogspot.com/2009/07/phases-of-data-migration.html

6. Phases of Data migration: Analysis
http://improveprocess.blogspot.com/2009/07/phases-of-data-migration-analysis.html

7. Phases of Data migration: Design
http://improveprocess.blogspot.com/2009/07/phases-of-data-migration-design.html

8. Phases of Data migration: Test
http://improveprocess.blogspot.com/2009/08/phases-of-data-migration-test.html

9. Phases of Data migration: Validation
http://improveprocess.blogspot.com/2009/09/phases-of-data-migration-validation.html

10. Data migration: Risks
http://improveprocess.blogspot.com/2009/09/data-migration-risks.html

11. Tips for Successful Data Migration.
http://improveprocess.blogspot.com/2009/10/tips-for-successful-dat-migration.html

Tips for Successful Data Migration.

2009-10-08T22:13:00.000-07:00

Maintain your sense of humor.
Expect delays and/or road blocks.
Run the data migration using traditional project principles.
Secure alignment and approval from steering committee and stakeholders as changes occur.
Appreciate the inter-dependencies.
Understand your business process, data, system and application landscape. (Devil is in the details)
Get the right software tools.
Use the right resources.
Plan for down time.
Perform at least two dry runs (Wash Rinse Repeat)
Develop risk mitigation plan.
Communicate your plan early and socialize with all impacted users.

Intelligent part numbers! Why and Why Not, Can PLM / ERP systems help?

2009-10-07T22:42:00.000-07:00

All companies that make and sell products have to make this decision very early on. Some companies might not have the maturity or business processes in place when this decision needs to be made. Changes to policies done at a later time could result in additional complications so most companies chose to remain on their current policy and process.

Intelligent part numbers are used to clearly identify the type of part, its commodity or sometimes even the location of use in the overall product. Typically companies develop a matrix mapping commodity to specific sequences of part numbers. For example 12-???? Could represent sheet metal, 13-??? could represent PCBs and so on.

Unintelligent part numbers on the other hand are based on ERP/PLM system’s ability to automatically generate the next higher number.

Companies that develop intelligent part numbers can clearly distinguish between top level products and lower level assemblies easily, in addition be able to develop logic to drive procurement, review and approval cycles based on part number sequences.

Developing part number sequences can be costly, they require manual setup, customization of applications (ERP, PLM etc.) and require due diligence on the part of engineers to follow a defined process. Depending upon the rules, the business groups must pay attention to number of possible parts for a given commodity (by projecting in to the future) and also plan on adding new commodities as the need arises. Typically this could require an additional head count to manage the process and tools. In my experience, a lot of engineers would rather focus on innovation and turn out their designs and go quickly from concept to prototype to production release and not be bogged down by having to pull a new number and update their documentation and slow things down.

Unintelligent part numbers provide engineers with the ability to conceptualize their design and generate new numbers easily with minimal data in the beginning and quickly release their designs and then provide additional data. Often engineers might not know what the right commodity / material needs to be when they are working on a concept. This lack of knowledge typically results in non value added work in recreating parts with the right material and commodity if they had made a mistake. Unintelligent part numbers do have a drawback which is that it doesn’t provide any information on the part type or any other data.

As ERP & PLM systems have matured, most have introduced a classification scheme / module with which parts can be classified. Typically classification systems capture information like whether the part is OEM or not, commodity, material, assembly or not, compliant or not (for RoHS, WEE, Reach etc.), Critical part or not, in addition the description can be broken down to clearly identify the parts. For e.g., socket head cap screw could be classified into a class of screws with a sub group of socket head or not and so on.

So if we can get so granular and capture all the information we need, we could use the classification system to drive activities like procurement based on commodity, ABC coding by commodity / part class and conditional workflows for ECO cycles based on part type and whether a full review is required or not. In addition, there are other uses like knowledge management and capturing the right questions when quality issues occur based on type of part/product.

New part creation could be streamlined by checking against classification schema and existing parts to see existing parts can be re-used. This re-use has a lot of benefits. I have seen/heard of benchmarks done by a number of companies where they have found that the cost of a part through its lifecycle (concept to obsolescence) is around $3000 to $5000.

Implementing a classification system is more complex than implementing intelligent part numbers. If you chose to do this mid stream, you will need to launch a data quality / clean up program to ensure data integrity and adherence to rules of classification and then launch this activity.

In summary, there is no easy answer for the debate on intelligent vs. unintelligent part numbers. Classification systems provide a lot of merit which outweigh the effort required clean up existing data and setup a new system.

Unified Task Dashboard! Utopia?

2009-10-05T22:02:00.000-07:00

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!

Primer to ERP

2009-09-23T23:30:00.000-07:00

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.

Best of Breed vs. Integrated Systems

2009-09-23T23:08:00.000-07:00

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.

How many applications do you need to run your business?

2009-09-23T22:48:00.000-07:00

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 :)

Keep Your IT Project On Time

2009-09-21T23:05:00.000-07:00

3 succinct tips from HBS on how to keep projects on time.

Key takeaways:

(1) align with your projects to business needs and strategy or you will lose
(2) Focus on immediate and pressing needs, "nice to haves" can follow. I have found the 80/20 rule to work well. This aligns well with my mantra "Think Big, Act Small, Move Quickly"
(3) Anticipate delays and plan well. Risk Mitigation and proper project planning always help in successful project implementation and execution.

Happy Reading! http://hbdm.harvardbusiness.org/email/archive/managementtip.php?date=092109

In Demand – Data Analytic & Reporting Skills

2009-09-21T22:34:00.000-07:00

I recently came across a number of articles on the latest hot skill “Data Analytics”.

With the explosion of information in recent years, companies are under severe pressure to capture opportunities ( increase revenue, profit, efficiency and customers) within a limited time period. This has resulted in a substantial increase in positions responsible for data analytics in order to convert massive amount of information (user behavior trending, adoption, etc.) into meaningful data.

By focusing on the technology know-how or purely number crunching abilities, companies might not reap the benefits of hiring additional head count. The ideal hire profile should include good understanding of business operations and processes in order to translate the data into insights.

There has always been a need for people with good analytical skills who can transform information into meaningful strategies for the business to pursuer revenue/cost reduction opportunities…This skill in most cases cannot be taught in school or by courses offered by a number of institutions. This comes about by having hands on experience and innate curiosity and interest in the big picture.

Tips to those who are embarking on this career path, (1) focus on big picture (2) focus on interpreting results and presenting them from a business case (3) technology often changes, methodologies and sound logic rarely do…

For companies, embarking on business intelligence / Data warehouse solutions, focus on business needs and understand your current reporting capabilities and see if your current staff can support the current and future requirements…a new tool might not be productive by itself…a focused training / learning session on adopting best practices in data analysis and reporting might be of great benefit to your current employees and enable them to grow professionally.

IT change management part 1

2009-09-18T22:36:00.000-07:00

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.

Data migration: Risks

2009-09-15T23:24:00.000-07:00

Risk management should be part of every project, especially a large scale migration project. Risks related to schedule, costs and scope should be clearly identified, documented and a plan must be put together to mitigate them.

In my experience, risks specific to data migration come from a number of contributors like

(1) data quality

(2) extraction, transformation and load tool complexity

(3) performance of systems (extraction and target system persistence)

(4) coordination of project activities as related to testing, UAT, system preparation

(5) resource constraints

Data quality:

Without a thorough understanding of the business rules and logic related to how the information is stored within the source and target system all migration projects are at risk.

Even if you understand the rules from a system perspective, try and get a handle on how the business uses this information. In some cases, even after a thorough mapping exercise, gaps could arise due to data issues…in such an event additional cycles will be required to re-map and re-run the extraction, transform and load routines. Don’t underestimate the work effort required to cleanse the data…in some cases, the risk mitigation steps involve leaving the source system as-is and including additional logic

Extraction, transformation and load tool complexity

As business systems add more functionality and modules, data migration becomes an extremely challenging exercise. In the past, data migration of metadata could be easily accomplished by writing data directly into the database(s) by using simple commands and flat files at the database layer. As business systems have matured, most of the times the database layer doesn’t contain the hierarchy and relationship information…these are stored and managed within the application layer. Extraction and loads have to use the application APIs and in some cases, these are not conducive to support extraction and loads in a mass manner. Often, schedules are adversely impacted due to added cycles of development to find/develop routines and software to support the extraction, transformation and load.

I would highly recommend contacting the software vendor and request reference information and talk to other customers/users that have been through a similar exercise and learn from their experience. Benchmark exercises like this will help in setting a timeline for such activities… Risk management could involve adding additional resources to drive closure of risk items. If additional cycles from software vendor are required, engage your vendor management team and actively manage your contacts at the software vendor. Escalations and jeopardy’s should be raised so that executives within your organization and the software vendor are informed about potential impacts and risks…

Performance of systems

Bad performance of business systems could lead to delays and inability to complete a load in the allotted time. We have talked about the complexity of the extraction, transformation and load routines…with added complexity it will be no surprise that most systems are not setup properly to support mass migrations…in fact different settings are required within application /business systems to support migrations and these could be totally different from what is required for day to day operations…

Thorough testing with multiple wash-rinse and repeat cycles are essential to clearly identify performance issues…in some cases, because of a n – tiered architecture, you might run into bottle necks at the application front ends or at the database layers…ensure your best performance people are monitoring the load process and can tune the systems properly.

From an database perspective (Oracle or others…), you might need to increase the memory allocated along with updating indices on a frequent basis as well as maybe even turning off archiving…another thing to do is maybe turn off search indexing within business systems to speed up the load process and perform this activity as a post go-live activity.

The key is to able to load all the data within the allotted time frame, some times risk mitigations might involve loading over a prolonged period, added front ends, additional memory and CPU’s, database/business system tuning.

Project coordination

Most often data migration projects are part of a larger project to implement a new business system. In these large scale implementations, there are a number of activities which must be completed for e.g. system design, configuration, process design, data mapping, unit tests, user acceptance test etc. data migration tests need to be performed so that all elements of testing can be done. This requires a high degree of coordination and any slips in code development, design configuration or testing cycles will impact the overall schedule and time allocated for data migration.

Risk mitigation could involve procuring a separate environment to conduct all data migration tests. In addition, ensure that all project activities which could impact migration are clearly identified and have the necessary dependencies captured within the project plan. Having a project review similar to scrum reviews can be beneficial.

Resource constraints

In an ideal world, all projects would be funded and resourced well with proper resource leveling. In the real world this rarely happens, the same is true with most of the migration projects I have managed. Typically the roles for project manager, business analyst, data experts, process owners and code developers are all merged and melded together and these resources have to wear multiple hats through out the implementation of the business system. In order to mitigate any risks to schedule and costs, clearly identify the resource requirement and secure the resources required ahead of time. The later you start; the chances of securing resources will be limited. Contract resources for execution of the extractions and loads can be viable option but requires clear documentation of the process and thorough knowledge of what needs to be done. If you have the right resource and have a plan, migrations can be handled with a set of contract resources…

Phases of Data migration: Validation

2009-09-15T22:26:00.000-07:00

This is a key phase to ensure success of the overall migration effort! Validation sounds easy but how do you go about it?

I have always setup a 3 tiered validation criteria,

• First level validation is to ensure that the records from a count perspective made it in to the target system.
• Second level validation to ensure that the key data elements made it into the target systems. The key data elements I look for are data that are essential to the running of the business. Another condition I have used is select data that is part of the object’s properties and are required fields within the application layer. For e.g. part unit of measure, cost are part of the object’s key attributes in ERP/PLM systems,
• Third level validation is to ensure the metadata for attributes and keywords that are nice to have but don’t have a significant impact to the business if they were incorrectly loaded.

I approach validation from three perspectives with a focus on

• Ensuring proper extraction from source system
• Ensuring proper data transformation into flat files (CSV, XML etc.)
• Ensuring proper load into target system

If you analyze failures or errors, you have to start by reviewing what you extracted. If you have any doubts at this layer, then the success of the overall project will be in doubt. If the data is properly extracted but incorrectly populated into a flat file, then your load will not be successful. If you have been successful in extraction and transformation and have properly tested the loads then you should have the data loaded successfully into the target system.

One key issue always pops up when it comes to validation: WHO is responsible? In most cases, the business owners point to the IT guys and IT guys point to the business owners. In order to be successful, engage both teams and work through the development of validation criteria, success criteria and identify what can be automated, validate the automation routines so that both sides are satisfied.

Automating this activity is almost a must in most cases, when you are faced with gigabytes or even terabytes of data manual lookups will not be sufficient. You could get fancy and dabble with sampling theory. In my opinion, go for 100% checking by putting technology to work!

Convert Failures into Success!

2009-08-31T23:06:00.000-07:00

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.

Phases of Data migration: Test

2009-08-27T23:49:00.000-07:00

Before any data is moved, it is important that some portion of the migration plan be tested and validated. Results of the migration test determine whether modification of the migration plan—for example, time line, migration tools used, amount of data migrated per session, and so on—is required. For example, if testing shows that allowable downtime would probably be exceeded, the migration methodology needs to be revisited.

Testing is a key element of the overall lifecycle of the project. Why? It

(1) proves the capability of migrating the data with no impact to the enterprise

(2) provides a good understanding of risks

(3) provides the ability to accurately define the sequence for the final migration including timelines

Start this process by reviewing the outputs from the analysis and planning stages. Engage a cross functional team and assess the capabilities, knowledge and expertise of the team. If the team has the skills, knowledge and expertise and has gone through a similar exercise in the past, then this phase is greatly simplified. Follow the same sequence as identified early.

In most cases, you might have to start from scratch. In that case, start by outlining the dependencies for data extraction, sequence them in the proper order, once the data is extracted from the source system, validate against the target system to ensure data integrity and then proceed with a sample load.

This is the time to engage your IT administrators to the fullest. Review application, database, network and infrastructure architecture and optimize from a data migration perspective.

For e.g. most data migration projects involve persistence in databases but this activity needs to be kicked off from the application layer following a syntax and methodology involving some structure in flat files (txt, xml etc.). In this case, the application and databases need to be tuned to identify the right parameters which will enable you to accomplish the load in a timely manner.

If you have distributed or federated systems, you will need the assistance of network and infrastructure administrators/architects to tune the network and servers from optimum performance, for e.g. remove bottleneck processes or establish a dedicated network etc.

This phase doesn’t conclude with successful migration and establishing a proper timeline for go-live. It should also include testing of post go-live activities. In most cases, search engines will need to be updated so that the indices are refreshed with the newly loaded data. there a number of such related activities that are tied to post go-live which are usually overlooked causing performance nightmares upon start up after data migration.

Keep at it, you can almost see the light at the end of the tunnel, next phase is validation. Remember the mantra “I love data”

Design for Manufacturability

2009-08-26T23:15:00.000-07:00

According to Wikipedia, Design for manufacturability (DFM) is the general engineering art of designing products in such a way that they are easy to manufacture.

The keywords to pay attention to are “art of designing products” and “easy to manufacture”. How many times have you bought a piece of furniture or toys for your kids and been stuck in the middle of the instructions because it wasn’t intuitive or if you were questioning the use of some material. For example recently I had to assemble safety gates to prevent my toddler from going up or down the stairs and I was puzzled by the use of plastic to fasten the gates to the walls.

In my mind IKEA has mastered the art of design for manufacturability. Some of the key features of their products that I like are
(1) simple design with minimal parts
(2) common parts and materials
(3) design for ease of assembly
(4) modular design with sub-assemblies
(5) mistake proof instructions (poke yoke)
(6) tools /kits necessary are clearly identified if not provided within the package

Companies embark on this process improvement methodology to
(1) reduce costs
(2) standardize manufacturing process
(3) reduce churn in design through ECO cycles which could be expensive if done later in the product life cycle
(4) get better control over product configuration and architecture
(5) eliminate/control risks related to reliability, manufacturability, feasibility, quality and liability

Some of the other benefits include
(1) get it right the first time
(2) lower production cost
(3) higher quality
(4) quicker time to market
(5) increased potential for automation
(6) increased re-use of components and fewer parts to manage via MRP/procurement cycles
(7) fewer ECO cycles

How do we go about design for manufacturability?
(1) Get your requirements clearly defined using MRD process
(2) Start to simplify designs and embark on optimizing product configuration and architecture
(3) Develop strategy for options / replacements per customer request
(4) Minimize number of parts and re-use components whenever feasible
(5) Reduce the number of specials manufacturing instructions (tolerance, surface finishes)
(6) Use the right materials to get the job done
(7) Increase collaboration between engineering/product development teams and the manufacturing teams
(8) Review design often and use a cross functional audience to explore options to reduce costs, increase re-use, reduce development time
(9) Use lessons learned from the past on failures and shortcomings of similar designs and avoid making the same mistakes

Career Advice from Top CIOs

2009-08-12T21:51:00.000-07:00

Great article from CIO.com with great insights and tips from great mentors.

the key takeaways: take ownership, don't be afraid of details, get your hands dirty, pick the projects that nobody else wants, admit your shortcomings, focus on your managers needs and fulfil their needs!

What is operational excellence?

2009-08-10T22:23:00.000-07:00

As usual I will start by quoting the definition from Wikipedia, “Operational Excellence is a philosophy of leadership, teamwork and problem solving resulting in continuous improvement throughout the organization by focusing on the needs of the customer, empowering employees, and optimizing existing activities in the process.”

If you read through the definition, you can clearly identify the key tenets: leadership, continuous improvement, focus on customer, and optimizing current processes. Simply put, operational excellence is executing in an efficient and effective manner across the value chain with a focus on delivering value to customers.

The Operational Excellence program provides a framework to understand why and how performance needs to improve. The road to achieving operational excellence is by identifying value chain business processes, identifying strengths/weaknesses of them (based on key measurements and benchmarks) and redesigning these processes to align with corporate / strategic goals and ensure that organizations, resources and assets are utilized in the best possible manner.

When you pore through the reference material on operational excellence, you will see terms/phrases like “on par with industry”, “best in class”, “world class”. There are differences in all these phrases, if you choose to embark on operational excellence, focus first to meet/exceed your competition’s performance and then become the best of your peers and then become the best among organizations outside of your industry and region.

Each and every industry and organization/business unit within each company can create and run their operational excellence program. In most cases, value chain processes span across multiple organizations, so the focus should be on process execution (related to handoffs) and ensure the best use of assets and resources across the enterprise. Automation and business process re-engineering have great potential so does streamlining / integrating data and business system like ERP, CRM etc.

How to manage knowledge within CAD

2009-08-07T23:35:00.000-07:00

In a series of posts, I will discuss my thoughts on how we can manage knowledge and leverage lessons learned to effectively and efficiently manage the product design process. In this post, I have outlined a few ideas and technology on promoting knowledge management and design re-use within the CAD domain.

CAD users, like engineers and designers, work in a fast paced environment with the pressures of reduced time to market and faster design cycles. In most cases, this results in little or no design re-use. Over the last 10 years, CAD vendors have come up with many features like
(1) shape indexing
(2) user defined features
(3) saved sketches/profiles

Shape indexing is an excellent feature by which the CAD system indexes shapes used within 3D models and alerts users when they are trying to recreate a similar shape. This can be tricky to implement and manage but has many advantages once you overcome the teething pains. Much like document/metadata indexing, shape indexing can be configured for optimum performance.

Multiple studies have indicated that 25-40% of designs are duplicates. While this might be warranted per business processes like interchangeability, we should be mindful of unintentional waste of resources. Shape indexing can be the key to improving efficiencies. In the past, I setup PTC’s ModelCHECK and was impressed with the results.

User defined features and saved sketches are similar in scope. These capture certain pieces of design that are often repeated. By creating these using best practices for design, users can embed these in a plug and play manner by just specifying the references. This saves $$$ in wasted repeated non value added tasks.

Metadata, like part/assembly description (or names), revision, manufacturer name and number are often not standardized. These tidbits of information when managed properly can support design re-use greatly. In most cases, since manufacturer part #/descriptions are not properly managed, engineers waste valuable time in modeling hardware like nuts/bolts/washers etc, when they could be focused on design and adding capability to their products. Again, tools like ModelCHECK can greatly contribute significantly by ensuring that standards are followed and adhered to.

Customer Experience Management!

2009-08-06T23:17:00.000-07:00

With increased focus on systems and internal processes within most companies, customer experience seems to have been missed.

While addressing issues within business systems and business processes to improve efficiency, cycle time and efficiency is good, the focus should be placed on the customer first. Ensure that you have
(1) the right offers/experiences setup for your customers
(2) processes and systems by which the offers/experiences can be served to your customers
(3) focus on end to end execution of business processes and not within individual organizations to ensure customer satisfaction, in most cases hand-offs between organizations cause significant delays and adversely impact customer experiences
(4) ensure repeated delivery of value to your customers

These 4 points apply to all types of customers (not just the ones buying the products/services of your company...)

Do you know what your customers want?

2009-08-05T22:09:00.000-07:00

I read an interesting blog post on "How Knowledge Can Hurt Innovation", which clearly illustrated how most of us assume that others are aware of what we know and what we are talking about.

After years of managing of technology and business processes, I have learned to listen to my customers (internal and external) and make sure that I have understood their requirements and follow up with multiple sessions of deep dives and alignment to ensure that my understanding matches their requirements.

What you say may not match what your customers heard, and the converse is true, what you heard may not be what the customer told you. Don't make assumptions in important projects. Constantly challenge yourself and your teams to check if your assumptions and views are aligned with customer expectations.

Cost Benefit Analysis

2009-08-04T22:35:00.000-07:00

As part of problem solving approach, you will end up with multiple solution options, how would you evaluate each of these and pick the optimum solution?

Cost Benefit Analysis (CBA) is one of the evaluation techniques to identify the right solution; it is a widely used technique to analyze solution options and decide on an approach to remedy a problem or implement a solution for an opportunity. CBA provides a means for systematically comparing the value of outcomes with the value of resources required to achieve the outcome.

Generally feasibility studies analyze viability of projects and solutions; technical feasibility looks at factors like architecture and scalability primarily from a technical perspective. CBA focuses on economical feasibility and determines if a solution is cost effective and economically sound.

Best practices:

(1) CBA must document all assumptions

(2) CBA must contains at least 3 solution options, one of the options would be “no change” or “as is” condition, to highlight cost of avoidance.

(3) Customers /Stakeholder must be the ones to identify and determine how to measure and evaluate the benefits.

(4) Customers/Stakeholder must be interviewed to identify the potential impacts of new or modified systems.

(5) CBA must have data for 3-5 year time frame to paint a better picture of one time and ongoing costs and benefits.

Be mindful of the fact that both costs and benefits are made up of one time and ongoing elements.

Costs are made of the following elements:

Labor /Services- labor costs include the salaries and benefits of employees and contractors/consultants assigned to the project. Sometimes this may also be referred to as services costs.

Software – All applications or software which has to be purchased or programmed. This may include not only price of procurement but also cost of licenses over the maintenance time frame.

Hardware- Equipment required to implement solutions for e.g. CPU, storage, RAM, servers, laptops, desktops, workstations etc.

Training – costs related to training project team members, stakeholders, super users and the larger user community. This could include monies spent on training material, instructors, software, training delivery and workshops/conferences.

Depending upon the project type, you might need to look into additional cost items like materials, supplies, facilities, travel, lodging and telecommunications related costs. There might be projects or software implementations which would involve additional headcount requirements which may involve additional costs related to recruitment and so on.

A good place to start the documentation of costs would be the current setup Review activities and resources engaged in the current process this indicates the labor/service costs. Review current system architecture and identify all software applications, this will lead you to software costs, resources costs for administration and license/maintenance costs, hardware used and then to hardware’s cost, depreciation, maintenance.

Benefits are the services, capabilities, and qualities of each alternative system, and can be viewed as the return from an investment. To estimate benefits, first identify the benefits for both the customers and the organization that provides the service(s) to the customers. Start by analyzing a number of factors to thoroughly review all potential benefits like: Accuracy, Availability, Performance, Compatibility, Efficiency, Maintainability, Modularity, Reliability and Security. Some might refer to benefits as return on investment (ROI).

At a simplistic level, if you compare the costs and benefits of each of the solution options then you are doing cost benefit analysis. In later posts, I will discuss how this type of analysis can be combined with other techniques to evaluate all solution options for e.g. maturity of solutions, impact to business process, technical feasibility etc.

A CAD World without Standards

2009-08-04T00:10:00.000-07:00

an excellent article on impact of no standards...

http://www.caddmanager.com/CMB/2009/03/a-cad-world-without-standards/

Blog Disclaimer.

2009-08-03T23:24:00.000-07:00

I recently came across a number of articles on how (1) bloggers have now become authors of sponsored content...(2) Copyright violations via blogs. This has prompted this post: Disclaimer to my blog.

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) or anyone else.

My thoughts and opinions change from time to time; this is a natural offshoot of having an open and inquisitive mind. This blog’s primary purpose is to document how we can improve the efficiency and effectiveness of our customers by documenting an approach to problem solving, improving business process execution by analyzing a multitude of approaches and technological solutions.

In the past, I documented my thoughts and views in a document; to serve as a repository of knowledge and I intend for this blog to be the same. By posting on the web, others are welcome to learn from my knowledge and views but keep an open mind.

CAD standards, What/Why

2009-08-03T22:36:00.000-07:00

Standards in CAD (computer aided design) can be important enablers. Sometimes, designers and engineers complain about standards and the burden placed on them to adhere to standards and how this impacts their productivity.

I can emphatically state that CAD without standards is a recipe for disaster.

How can I back this up?
(1) I have over 10 years of experience in designing and managing CAD implementation (multi CAD, multi locations)
(2) I wrote the training manual for CAD standards and system administration and taught CAD/PDM administrators how to efficiently setup CAD environments and manage them effectively.

Benefits of CAD Standards include,
(1) Repeatability and quality of design
(2) Increased efficiency of drafters, designers and engineers
(3) Reduced costs by enabling reliable, standards-conformed, data

What should be included in CAD standards?
(1) Best practices for modeling

Include all aspects of design for e.g. casting, molding, chamfer, rounds, tolerances, inseparable assemblies, mirror etc. Document the processes with references to part number conventions used within the organization so that all users can name their assemblies, parts, features in a consistent manner and follow the same process/procedure to create 3d models.

(2) Best practices per CAD software

Every CAD package manages parent-child relationships in a different manner. Parent child relationships sometimes cause extensive problems in CAD data management and upgrades of PDM systems. Try and leverage the best practices per the vendor or the user community.

(3) Design drafting standards

Modify templates (for parts, assemblies and drawings) and configuration files to use the right units, views, drawing conventions like symbols, notes, tolerances, arrows, cross sections etc.

(4) Attributes/Metadata

Include attributes into the templates (for parts, assemblies and drawings) and prompt the user to enter this information as part of the creation process, this will ensure that the information entered is consistent. In most cases, if this is not entered during creation, it never gets captured. Most CAD packages have the capability to allow the drawing tables to be populated based on part/assemblies linked to them. In addition, this information can be passed from CAD into PDM systems and then into PLM/ERP systems.

(5) Software Configuration

Ensure that the software configuration on client's machines are consistent. If you dont control this configuration, then users can modify the settings and you will end up with standards not being followed.

If you don't include internal best practices/design drafting standards and match them with CAD vendors' best practices, you could end up with a mess on your hands. CAD systems are complex, and if you allow your users to have a free reign, data management becomes a hassle and will have a significant impact on down stream processes used within supply chain and manufacturing.

In a later post, I will discuss how to go about setting standards & how to go about cleaning a messy situation!

Phases of Data migration: Design

2009-07-31T23:31:00.000-07:00

Now the fun begins! :)

In previous posts, we had focused on phases of data migration, and looked at planning and analysis stages in detail. In this post, we will focus on design of the tools and methodology for data migration.

What tools do we need? We will need at a minimum three tools for

* Extraction & transformation
* Load
* Validation

The first item to complete would be data mapping from source to target system. Based on the scope identified in the planning stage, have your business analysts dig deep and clearly identify all data sources, formats/rules and map them to the target system. This mapping exercise needs to be comprehensive for e.g. simply mapping name of the customer is stored in table XYZ and in column 1 in source system to table ABC and in column 2 is not enough. Why? In order to be thorough, you need to consider the maximum length of characters in your source system and check to see if your target system can handle this.

If your target system cannot handle this length, you have some choices (extend character size, truncate some customer names etc…). Regardless of decisions, this will have to be captured in your planning assumptions, socialized and then documented in your design document.

Word of caution: Don’t make assumptions! Don’t trust anyone! Including your data experts. Have your experts prove their knowledge of the data and their expertise. The reason for this seemingly paranoid approach is justified; in a lot of cases “knowing the data” means knowing the data base construct and limited knowledge of how the business uses the data or sometimes the other way around knowing the business logic but having no clue of persistence at the database layer.

Once your data mapping is done, you will have a clear idea of any data cleanup that needs to be done. Drive your team to think in terms of numbers and impact to schedule. The numbers should indicate the number of (1) records that have to be fixed/cleaned, (2) resources required to perform this clean up (3) hours/dollars effort/cost impact.

If data cleanup is required, consider this as a separate body of work. Don’t scavenge on the design activity to fund or resource the data cleanup. If you need additional help, make sure you raise awareness/jeopardy and ask for help.

Continuing on with design, ETL (extract transform and load) utilities can be challenging, but you don’t have to reinvent the wheel. Think outside the box, in most organizations that focus on KPI’s and performance metrics, there will be well defined tools to extract data. These tools can form the skeleton for your extraction tools. Review these carefully and document, what else you might need. If you are starting from scratch, try to get the experts to document the application layer and database layer. Once you have an idea of how source system manages and stores data, you can work towards extraction. With the advent of J2EE based systems, pure database centric extractions have become exceedingly difficult. The reason is that the logic and rules for extraction exist in the application layer and may not be clearly available in the database. In some cases, I have spent hours trying to create relationship diagrams using tools and that finally managed to construct diagrams based on combining application logic with some creative thinking (hacks) into the databases.

This activity of design and building tools to support data migration are no different from the equivalent standard SDLC tasks.

The key requirements for these tools are scalability and performance. Your tools should be able to perform the tasks within a timely manner and be able to handle the data set identified in the planning stage. While going through design, build and test iterations, I would highly recommend keeping a spreadsheet to record performance.

Thoroughly analyze the sequence for data extraction, load and validation. This is the sequence you need to solidify in the test phase and execute to during go-live. This sequence is usually identified as the last step and this is a common mistake. Instead of honing the strategy, data migration leads continue to spin their wheels.

Process Mapping: Part 2.

2009-07-24T21:36:00.000-07:00

In an earlier post, I had outlined how to construct a simple flowchart. In this post, let us see how can add more detail and enhance this flowchart using different techniques like SIPOC (six sigma), value stream mapping (lean), swim lane etc.

Swim lane diagrams: This is an extension of flowcharts and includes additional details like

Actors: The people, groups, teams, etc, who are performing the steps identified within the process.
Phases: These might reflect the phases of the project, different areas of the project, or any secondary set of key elements that the process flow needs to traverse to successfully complete this process.

Some times, these are also called cross functional flowcharts. This method of allows you to quickly and easily plot and follow processes and, in particular, the handoffs between processes, departments and teams and identify inefficiencies easily.
For example, if you look at the image shown, the flow chart is extended with additional information (phases are distinctly listed in the columns and the actors are listed in the rows).

SIPOC diagrams: This is an extension of flowcharts and clearly indicates the suppliers, input, process, output and customers. In some cases, the process can be shown not only in a simple flowchart but also using swim lanes. SIPOC depiction of the process is very useful because it clearly identifies who supplies the information, which organization is impacted by the process and who generates the output and what the deliverables are.

Value stream mapping: This is an extension of flow charts & swim lanes and clearly identifies management and information systems that support the basic process. This methodology started as part of LEAN manufacturing with an emphasis on reducing wastes within manufacturing, but the benefits of using this across all business processes are valuable. The primary goal of this depiction is to clearly identify value added and non value added tasks performed in order to minimize wastes. It clearly outlines all tasks tasks, cycle time for each of the tasks so that the reviewer/management can identify how the process can be improved.

Process Mapping: Part 1

2009-07-23T23:42:00.000-07:00

Process Mapping refers to activities involved in defining a business process (Who does What, When, Where, how and Why). Once this is done, there can be no uncertainty as to the requirements of every internal business process.

It is a visual depiction of the sequence of events that occur from the beginning to the end of the business process.

Process maps can be constructed using a number of different techniques like flowcharts, swim lanes, process maps. Six Sigma methodologies recommend using a SIPOC approach. SIPOC stands for supplier, input, process, output and customers to clearly identify the handoffs, the inputs and outputs.

Let us start with the simplest approach, a flowchart.

How does one create a process map with a flowchart?

Step 1: Determine the Boundaries: Identify the start and end of the processes. Observe the process in action (if possible).

Step 2: List the Steps in the process. My recommendation is to start with post-it notes, identify the steps.

Step 3: Sequence the Steps: now place the post-it notes in the order

Step 4: Draw Appropriate Symbols

Start with the basic symbols:
Ovals show input to start the process or output at the end of the process.
Boxes or rectangles show task or activity performed in the process.
Arrows show process direction flow.
Diamonds show points in the process where a yes/no questions are asked or a decision is required.
Usually there is only one arrow out of an activity box. If there is more than one arrow, you may need a decision diamond.

Step 5: Finalize the Flowchart

Check for completeness and duplication/redundancy
Ask if this process is being run the way it should be.
Do we have a consensus?

Here is an example of flow chart.

Architect!

2009-07-23T22:53:00.000-07:00

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.

Phases of Data migration: Analysis

2009-07-21T23:34:00.000-07:00

This is probably the trickiest part of the project. It all depends upon how well you know your data!

In an earlier post, I had outlines the characteristics of good data. Focus on the following items in your analysis.

* Completeness,
* Conformity,
* Consistency,
* Accuracy,
* Duplicates, and
* Integrity

Based on your scope, try and identify all the sources of data (business systems like ERP, CRM, MES, PLM, document management systems etc.). Once you have the source identified, identify the quality of data.

If you have business analysts on your team, put them to work to

(1) document business rules and logic in source and target systems

(2) document gaps in data conformity to existing business rules and business processes

(3) document duplicates and plan of action to address duplicates

(4) document data integrity gaps and plan of action

(5) document plan to map data from source to target systems

Your business users should be assigned to

(1) assess completeness of data

(2) assess impact of data mapping

(3) assess data quality issued reported by business analysts

Based on the two bodies of work, you will have a good idea as to whether you need to clean your data prior to the move! In my experience, you will have some tough choices to make: Clean source data or design your extraction utilities to account for the cleansing actions!

I would recommend focusing on this aspect. “Garbage In is Garbage Out”

Overcome Your Fear of Trying Something New

2009-07-21T23:26:00.000-07:00

Great article on empowering yourself to expand your horizons.

Be Real, Be Whole and Be Innovative!

Organized Information is the Next Moonshot?

2009-07-21T22:44:00.000-07:00

I came across a very well written article on organized information!

Kudos to the author on succinctly writing about the value of organized information!

An excerpt from the article “Today's challenge is not having more information; it's devising a less-resource intensive way to collect it and an efficient way to filter and disseminate it.”

It is not what you know; it is how well and how quickly you can use what you know!

Phases of Data migration: Planning

2009-07-21T22:34:00.000-07:00

In an earlier post, I had outlined the key elements of a data migration plan. Now let us delve into the details.

(1) Scope: Clearly identify what data needs to be migrated over from the source system into the target system. Insights of subject matter experts are invaluable, Use them well! Work with your team, to identify what needs to be migrated, base the decision on how the business process will have to be executed in the new system and what information is essential to ensure success, effectiveness and efficiency. In every migration project I have managed, this is a crucial building block. At the end of this stage, you should have Estimate of the data assets (number of records, metadata, documents etc.)

(2) Criteria for a successful migration: this deliverable is closely tied to the scope of the data migration. Migrating the data into the target system without any errors doesn’t mean the project was successful; focus on what your customers will need! The criteria should start with error free migration and also include impact to customers if additional cycles are involved. This will take a few iterations, engage your subject matter experts and end users and work with them to refine the scope and define the criteria for success.

(3) Decision making authority of each of the data domains: In my experience, ownership of data is a tricky item. Different groups may own pieces of information that make up usable data to the enterprise! First identify the data elements and then start asking for who is the owner or steward of this data; this will lead you to decision making authority. Ensure that this person is always engaged, communicate often and well! Without their buy-in, scope and criteria for success will be meaningless.

(4) What data needs to be migrated: in almost all cases, all the data mayn’t be required. Consider the lifecycle of the information, in most cases the data can be divided into three buckets

a. Currently relevant to business

b. Historic information for archival / research purposes

c. Newly created, which may not have any significant value yet

Consider these buckets well, in most cases you might need to splice the data and truly identify all facets of usage. Dig deep and clearly identify usage patterns, this will indicate the value of your dataset and will provide insight into your final decision of partial or complete migration

(5) Timing: this is a key element of your plan. You need to clearly identify the time line for cutover into production. Work backwards from go-live date and identify spots for key tasks like development of extraction, loading and validation utilities, test runs (at least 2-3), stakeholder acceptance tests. You mayn’t have a clear idea of time needed to load into target system, work with your software vendor or benchmark with companies/individuals who have worked on similar systems and assess the time required for final migration.

(6) Requirements: focus on resource, system (hardware/software) and budgetary requirements. Gather as much information as possible from benchmarks and vendors to clearly identify what you might need to ensure success of this project. Start communicating the requirements to program sponsors, your resources and stakeholders, get alignment and then go secure the requirements.

(7) Roles and responsibilities: clearly define the roles and responsibilities for each and every one on your team. At a minimum, your team should include

a. Project manager or lead

b. Business user

c. Business analysts

d. Data architect and or data administrator

(8) Assumptions: this is a key element of any project, as you define the scope and success criteria, ensure that your assumptions are well documented and communicate them. Ensure your stakeholders, program sponsors and decision making authority are aligned. If you ever have to change any of the underlying assumption, secure alignment again.

(9) Risks and Risk Mitigation: every migration project is fraught with risk, if you remember an earlier post, I had outlined the success rate of projects and this paints a dismal picture. For every risk, ensure you have a risk mitigation plan. Document the risk and communicate your plans and secure alignment before proceeding.

Phases of Data migration

2009-07-11T17:30:00.000-07:00

Just like SDLC, I would like to propose distinct phases and stage gates that have to be met in order to complete data migration.

(1) Strategy

(2) Analysis

(3) Design (& build)

(4) Test

(5) Validation

In this post, let us focus on the strategy or planning phase. The first step is to put together a plan. The data migration plan should describe, in detail,

(1) Scope of the project

(2) Criteria for a successful migration

(3) Who is the decision making authority of each of the data domains (should be from the business organization)

(4) What data needs to be migrated (full or a subset)

(5) Timing

(6) Requirements from hardware, software perspective

(7) Resource requirements

(8) Budget requirements

(9) Roles and responsibilities

(10) Assumptions

(11) Risks

(12) Risk mitigation / Contingency

The plan also sets expectations up front with customers about the complexity of the migration, timing, and potential issues and concerns. Remember this is the first cut at the plan; this can be refined as move along your project. If you make any changes, remember to socialize with governance and accountability system.

Rules For Successful Data Migration

2009-07-11T17:02:00.000-07:00

(1) Clearly define the scope of the project

(2) Actively refine the scope of the project through targeted profiling and auditing

(3) Profile and audit all source data in scope before writing mapping specifications

(4) Define a realistic project budget and timeline, based on knowledge of data issues

(5) Secure sign off on each stage from a senior business representative

(6) Prioritize with a top down, target driven approach

(7) Aim to volume test all data in scope as early as possible at unit level

(8) Allow time for volume testing and resolving issues

(9) Segment the project into manageable, incremental chunks

(10) Keep total focus on the business objectives and cost/benefits throughout.

Data Migration: Challenges & Joy! Part 2.

2009-07-10T19:30:00.000-07:00

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”

Data Migration: Challenges & Joy!

2009-07-10T19:00:00.000-07:00

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”. :)

Zachman Framework: My Experience

2009-07-09T18:00:00.000-07:00

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.

What is PLM?

2009-07-09T17:30:00.000-07:00

Product lifecycle management systems (PLM) were developed to help organizations control documentation, product structure and manage engineering change order (ECO, ECN, ECR etc.).

Product data management systems (PDM) have existed for a while prior to the development of PLM systems. The key differentiator between the two being lifecycle management in addition to data management. In most organizations, the engineering change process was

(1) Manual (process) with inefficiencies in handoffs between departments,
(2) Inability or lack of capability to capture financial impact
(3) Lack of awareness of extent/impact of changes and
(4) Unable to meet cycle time expectations.

As organizations continued to mature in their business processes (New product introduction, phase gate product introduction, product portfolio management, design for excellence [DFX, DFM], Excess and Obsolete inventory management, Effectivity dates) and business system usage (ERP, MRP, CRM), a need for a more comprehensive solution became compelling.

Research into product costs over its lifecycle has indicated that a focus on getting the design right earlier in the alpha/beta stages provides the maximum benefit. In order to get the design right so early can be tricky…effective business processes with right enabling technology will be the key to success to improve time to market and reduced costs across the lifecycle.

Three different sets of companies started developing PLM software
(1) traditionally CAD centric software companies, enhanced their PDM systems with additional capabilities
(2) ERP companies enhanced their core capabilities with enhanced workflow and document management features
(3) Pure PLM software vendors, which built their engines on basic needs of their customer base with extensive integrations to CAD (upstream data) and ERP/MRP/CRM systems.

There has been some amount of consolidation and over the years, PLM as a technology has matured and has added more and more features for e.g.
(1) Supplier collaboration
(2) Design / manufacturing outsourcing
(3) MES integration
(4) Digital rights management
(5) Collaboration
(6) Project management
(7) Regulatory and Environmental compliance tracking and management (RoHS, WEE, RoHS, FDA CFR etc.)
(8) Customer needs management
(9) Data Classification and Knowledge management
(10) Configuration management

And this list goes on…

In later posts, I will get in to details around each of these enhanced capabilities and future direction of PLM to support the enterprise.

Knowledge management

2009-07-08T18:00:00.000-07:00

I have long been a proponent of knowledge management – documenting insights, experiences and lessons learnt so that we don’t reinvent the wheel. In most cases, organizations and individuals tend to forget the lessons learnt in the past…

Over the last two decades or so, with the advent of enhanced document, content and metadata management solutions (ERP, PDM, PLM, Sharepoint, etc.) organizations have been able to document their best practices and lessons learnt to enable faster collaboration, innovation and problem solving.

There have been challenges such as the (1) need to classify and tag knowledge,(2) the need to clearly document experiences so that relative newcomers can come up to speed, (3) ability to search and find relevant data amongst thousands of documents (4) enforce creators and audiences of knowledge sharing to use the knowledge management system and positive value over time.

I was surprised to read an article on “When Knowledge Management Hurts” from http://blogs.harvardbusiness.org/vermeulen/2009/03/when-knowledge-management-hurt.html. An excerpt from this page “The advice to derive from this research? Shut down your expensive document databases; they tend to do more harm than good. They are a nuisance, impossible to navigate, and you can’t really store anything meaningful in them anyway, since real knowledge is quite impossible to put onto a piece of paper.”

I dug a little deeper and found “Does Knowledge Sharing Deliver on Its Promises?” from http://knowledge.wharton.upenn.edu/article.cfm?articleid=1841. This article clearly identified some of the shortcomings and listed some reasons why! The key takeaways from this article (my $0.02) are:
The first key implication is that it is unsafe to assume that more knowledge sharing is always better.
The second key implication is that it unsafe to assume that the net effects of using even the right type of knowledge are always positive. Instead, the design of a project team affects its ability to achieve the desired advantages of knowledge sharing.

As long as we continue to generate data, we should be able to leverage this! This will mean that users, employees and organizations will need to step back and understand the value in maintaining knowledge and experience within their boundaries and implement steps to capture, share and use knowledge effectively.

The Business Case for Data Management (MDM, Data Quality, Data Governance)!

2009-07-08T17:30:00.000-07:00

In an earlier post, I had outlined impact of poor data management. In this post I would like to discuss the data quality and need for governance/accountability systems and technological solutions like MDM (Master Data Management).
Characteristics of good data
In order to analyze the data stored with applications and used by end to end business processes, let us review certain characteristics to check if our data is of good quality and where/what do we need to work on:
Completeness: Is all the requisite information available? Are data values missing, or in an unusable state?
Conformity: Are there expectations that data values conform to specified formats? If so, do all the values conform to those formats? Are these formats specified in the same way across all your applications (data silos)?
Consistency: Do you have conflicting information about the same object? Are values consistent across applications and business processes (data silos)? Do interdependent attributes always appropriately reflect their expected consistency?
Accuracy: Do data objects accurately represent the “real-world” values they are expected to model? Are there variations in spelling or reference information (id related to customer, supplier and employees)?
Duplication: Are there multiple instances of the same data objects within your data set?
Integrity: What data is missing important relationship linkages? Does the data adhere to a predefined set of rules?
Timeliness: Can the right people access the right data at the right time?

The fundamental nature of data is that it changes continuously making it difficult for organizations to put the data to the best possible use and achieve benefits. Furthermore, much of the data within organizations resides on different systems (for example, ERP, CRM, Order management, Customer service, PDM, PLM etc). And it is often difficult to keep all these systems in sync.

Poor data quality isn’t always apparent in processing your day-to-day business transactions. The purchasing department, for example, may not see the difference between entering “3M” or “3M Corporation” or “3MCorp.” in a database. All of these seem to get the job done. But if you dig deep, you will find that this could potentially save $$$ in time and resources utilized in creating duplicates of data.

In most organizations, most resources are fully utilized and certain “nice to have” functions are dropped as a result. One such item that is commonly ignored is data quality!

The benefits of accurate data are clear. They include decreased product development and sales costs, better customer service and increased employee productivity. However, building the business case in order to launch a data quality management initiative has traditionally been a challenge!

As organizations face stiff demand and need to churn out products and services faster, there is an increased demand placed on the availability of good data to support faster and better decision making! Without a doubt, data has become the raw material of the information economy, and data governance is a strategic imperative.

In addition, increased requirements on timely and accurate data placed by regulatory compliances like (SOX, FDA 21 CFR Part 11, RoHS, WEE, Reach, HiPAA, Osha) have stretched the capabilities of process and business systems owners.

These demands have resulted in the development of data governance and technological solutions like MDM. Master Data Management (MDM) is the technology, tools, and processes required to create and maintain consistent and accurate lists of master data.

Some organizations hope to improve data quality by moving data from legacy systems (or consolidating data silos) to (ERP) and (CRM) packages. Other organizations use data profiling or data cleansing tools to unearth dirty data, and then cleanse it with an extract/transform/load (ETL) tool for data warehouse (DW) applications.

A word of caution: unless data quality and governance is approached from a top down manner with alignment from all levels, we will not be able to achieve accurate, complete and timely data! A program to address data quality is not to fix a business system or application, neither is it an implementation of technology solution like MDM, BI, DW. This program is to fix behavior, flow of information across the enterprise and improve operational effectiveness, efficiency, control and success. Merely focusing on technology will result in the same problems but in a different application.

Decision Making

2009-07-07T14:23:00.000-07:00

Thanks to Mala, I listened to a very interesting 6 minute monologue on decision making!
Recommend listening to it. Here's a link

Has CAD delivered on its promise?

2009-07-07T13:59:00.000-07:00

CAD (computer aided design) was a major boost to engineering productivity in the early 1980s. The capability of having drawings in digital forms, ability to overlay layouts to ensure form, fit and function were key enablers. As the usage of these software programs matured, the demand on additional features increased as well.

This led to the development of 3 D modeling capability; 3-D modeling was a huge step forward as it allowed for creating parts and assemblies and ability to
(1) Parametric modeling
(2) Capture design intent
(3) Associativity
(4) Finite element analysis capability
(5) Enhanced cam capability
(6) 3d rendering
(7) Interference / clearance checking

Over the last 10-15 years, the capability and maturity gaps between high-end and low-end CAD packages have reduced significantly. There has been some level of consolidation in the CAD space and software vendors have started creating more software packages to manage data (PDM, PLM) etc.

In my opinion, very few companies have mastered the art of the product data management specifically CAD data, which has resulted in lower re-use of existing components and wasted time and resources on recreating product data. Why is that?

Despite the promise of computer aided manufacturing (CAM) combined with the powers of comprehensive 3D modeling, very few companies have transitioned over to drawing less systems by utilizing CAM capabilities. Why is that?

Why is adoption of ASME 14.41 lagging? This standard supports the creation of 3D drawings with annotations and tolerance symbols. My $0.02, this could save $$$ in time and resources spent on creating product documentation via drawings.

I have long been a proponent of a single platform for product development using a single CAD tool. But this is an uphill battle in most large companies as companies go through acquisitions or relinquish control over product data management resulting in different groups using different platforms! This forms a major challenge to seamless collaboration. There have been a few promising software packages which allow for digital mockups by creating assemblies from different CAD packages. The major challenge here is that the mockups and changes done are not passed back on to the original CAD package. How can we enable cross platform collaboration?

Seamless integration with PLM/ERP
As the usage of PDM and PLM applications is increasing, there is an increased focus on the need product structure creation and maintenance. I would like to see complete integration between CAD and these applications so that editing of product structure (BoM) and attributes is seamlessly transferred in a bi-directional manner.

There has been some effort in analyzing part geometries to quickly identify if similar designs exist and promote re-use. This capability needs to be enhanced and promoted through out the user community.

In summary, we have come a long way but we can do more to improve how use the tools! We must innovate to try and identify more opportunities!

More postings on this topic to come...

The 10 Questions Every Change Agent Must Answer

2009-07-06T16:47:00.000-07:00

I came across this blog entry, from Harvard Business School. I highly recommend reading the article and going through each and every one of the questions to see whether you are on the right track!
It's time to do — and get — something different. Here, then, are ten questions that leaders must ask of themselves and their organizations —
1. Do you see opportunities the competition doesn't see?
2. Do you have new ideas about where to look for new ideas?
3. Are you the most of anything?
4. If your company went out of business tomorrow, who would miss you and why?
5. Have you figured out how your organization's history can help to shape its future?
6. Can your customers live without you?
7. Do you treat different customers differently?
8. Are you getting the best contributions from the most people?
9. Are you consistent in your commitment to change?
10. Are you learning as fast as the world is changing?

Key Performance Indicators

2009-07-06T15:48:00.000-07:00

Key Performance Indicators (KPI) are metrics used to help an organization define and evaluate how successful it is, typically in terms of making progress towards its long-term organizational goals.

KPI’s can be specified by answering the question, "What is really important to stakeholders?”. KPI’s evaluate business data against business goals and display current status by using easy-to-understand graphical indicators. For example, a KPI can use traffic light icons to indicate that customer satisfaction is exceeding, meeting, or failing to meet goals.

KPI’s are quantifiable measurements, agreed to beforehand, that reflect the critical success factors of an organization.

They will differ depending on the organization. A business may have as one of its Key Performance Indicators the percentage of its income that comes from return customers. A school may focus its Key Performance Indicators on graduation rates of its students. A Customer Service Department’s Key Performance Indicators could be percentage of customer calls answered in the first minute. A Key Performance Indicator for a social service organization might be number of clients assisted during the year.

Guidelines: refer to the posting Metrics

Categorization of indicators
KPIs can be summarized into the following sub-categories:
Quantitative indicators which can be presented as a number.
Practical indicators that interface with existing company processes.
Directional indicators specifying whether an organization is getting better or not.
Actionable indicators are sufficiently in an organization's control to effect change.
Financial indicators used in performance measurement

Are KPI’s and metrics interchangeable?
The term "metric" is generic. It is typically used to mean just about any sort of measurement applied to gauge a particular business process or activity. KPI’s are metrics, too, but they are "key" metrics. KPI’s are meant to gauge progress toward vital, strategic objectives usually defined by upper management, as opposed to the more generic metric used to measure a more mundane (i.e., less strategic) process. The goal is to foster greater visibility, better execution of strategy, faster reaction to opportunities and threats, and improved collaboration and coordination across key business operations

In previous posts, I had outlined SWOT analysis and setting strategy based on the analysis. KPI’s provide a way of measuring progress towards accomplishing the goals set by the strategy. In this post, I have outlined the definition and details regarding KPI’s and in upcoming posts, I will discuss performance management and evolution of balanced scorecards.

SWOT Strategy

2009-07-06T11:49:00.000-07:00

In a previous blog entry, I had described how to go about SWOT analysis. Now that you have completed the analysis and created a matrix of your Strengths, Weakness, Opportunities and Threats, let us discuss how you can construct a strategy to address your findings.

You will have to match each component with one another. For example, match the internal strengths with external opportunities and list the resulting Strengths / Opportunities strategies in the matrix chart. This will result in four strategy types, which are:

S-O strategies pursue opportunities that match the company’s strengths. These are the best strategies to employ, but many firms are not in a position to do so. Companies will generally pursue one or several of the other three strategies first to be able to apply Strengths-Opportunities strategies.

W-O strategies overcome weaknesses to pursue opportunities. Your job is to match internal weaknesses with external opportunities and list the resulting Weaknesses-Opportunities strategies

S-T strategies identify ways that the firm can use its strengths to reduce its vulnerability to external threats. Your job is to match internal strengths with external threats and list the resulting Strengths-Threats Strategies

W-T strategies establish a defensive plan to prevent the firm’s weaknesses from making it susceptible to external threats. Your job is to match the internal weaknesses with external threats and record the resulting Weaknesses-Threats Strategies

Here are some examples on the type of strategies based on SWOT analysi:

Strength-Opportunity Strategies
Expand
Increase advertising
Develop new products
Diversify

Strength-Threat Strategies
Diversify
Acquire competitor
Expand
Re-engineer

Weakness-Opportunity Strategies
Joint venture
Acquire competitor
Expand

Weakness-Threat Strategies
Divest
Retrench
Restructure

Pareto Analysis

2009-07-06T11:26:00.001-07:00

Pareto charts provide a tool for visualizing the Pareto principle, which states that a small set of problems (the "vital few") affecting a common outcome tend to occur much more frequently than the remainder (the "useful many"). A Pareto chart can be used to decide which subset of problems should be solved first, or which problems deserve the most attention.

The Pareto principle (also known as the 80-20 rule, the law of the vital few, and the principle of factor sparsity) states that, for many events, roughly 80% of the effects come from 20% of the causes. Vilfredo Pareto observed that 80% of the land in Italy was owned by 20% of the population.

This principle can be applied to quality improvement to the extent that a great majority of problems (80%) are produced by a few key causes (20%). If we correct these few key causes, we will have a greater probability of success. It is the basis for the Pareto diagram, one of the key tools used in total quality control and Six Sigma.

Step by step process:
1 List all elements of interest
2 Measure the elements, using same unit of measurement for each element.
3 Order the elements according to their measure
4 Calculate the percentage for each element out of the total measurement
5 Accumulate the percentage from top to bottom to equal 100%.
6 Create a bar and line graph, line representing cumulative percentage.
7 Work on the most important element first.

Quotes on Innovation & Leadership

2009-07-06T11:17:00.000-07:00

I recently came across a few quotes which I found very inspiring and felt that these captured the essence of Innovation & Leadership.

Enjoy :)

The ability to convert ideas to things is the secret to outward success. (Henry Ward Beecher)

A wise man will make more opportunities than he finds. (Francis Bacon)

Six essentials for success: Sincerity, personal integrity, humility, courtesy, wisdom and charity. (Gerald Roque)

In everything that ends well defined are the secret of durable success. (Victor Cousins)

People seldom become famous for what they say until after they are famous for what they’ve done. (Cullen Hightower)

It is curious that physical courage should be so common in the world and moral courage so rare. (Mark Twain)

Things that matter most must never be at the mercy of things which matter least. (Goethe)

The significance of a man is not what he attains but in what he longs to attain. (Kahlil Gibran)

If you don’t know where you are going, you’ll end up somewhere else. (Yogi Berra)

People who are quick to take offense will never run short of supply. (Unknown source)

The greatest enemy of the truth is very often not the lie - deliberate, contrived and dishonest - but the myth - persistent, persuasive and unrealistic. (John F. Kennedy)

The greatest of all faults is to be conscious of none. (Thomas Carlyle)

The biggest idiot can sometimes ask the questions the smartest man can’t answer. (Unknown source)

Our plans miscarry because they have no aim. When a man does not know what harbor he is making for, no wind is the right wind. (Seneca)

In the absence of clearly defined goals, we become strangely loyal to performing daily acts of trivia. (Unknown source)

The woods are lovely
dark and deep.
But I have promises
to keep
And miles to go before
I sleep.
(Robert Frost)

SWOT Analysis

2009-07-02T16:41:00.000-07:00

SWOT Analysis is a methodology used to evaluate the Strengths, Weaknesses, Opportunities, and Threats involved in a project or in a business venture. It involves identifying the internal and external factors that are favorable and unfavorable to achieving success.

Successful businesses and individuals build on their strengths, correct their weaknesses and protect against internal vulnerabilities and external threats. They can monitor overall business environment and quickly identify and exploit new opportunities faster than competitors.

SWOT analysis can be used for all sorts of decision-making, and the SWOT template enables proactive thinking, rather than relying on habitual or instinctive reactions.

SW – Strengths & Weakness are influenced by internal factors – the strengths and weaknesses of the organization or individual. These are competences and resources that the organization or individual possesses and that are under their control.

OT - Opportunities & Threats are influenced by external factors that an organization or individual faces from trends and changes in their environment. These external factors are not under the control or influence of the organization or individual

How do I go about it?

(1) Start with an objective

(2) Now/Present: identify your strengths and weakness,

a. Strengths

i. What are your advantages?
ii. What do you do well?

b. Weaknesses

i. What could you improve?
ii. What do you do badly?
iii. What should you avoid?

(3) Future/What might be?: identify potential opportunities and threats

a. Opportunities

i. Where are the good opportunities in front of you?
ii. What are the interesting trends you are aware of?

b. Threats

i. What obstacles do you face?
ii. What is your competition doing?
iii. Is changing technology threatening your position?
iv. Could any of your weaknesses seriously threaten your potential?

(4) Develop a plan of action to

a. maximize strengths to turn them into opportunities,

b. maintain and leverage strengths

c. convert weakness into strengths, create a remedial action plan to improve

d. counter or minimize threats, if not threats will turn into weakness

What is the impact of poor data management?

2009-07-02T08:15:00.000-07:00

• Reduced customer satisfaction due to incomplete, out-of-date or incorrect data
• Inability to bring new products to market quickly
• Depleted or overstocked inventory
• Loss of revenue due to billing errors and lost opportunity
• Lost manufacturing time due to inaccurate parts ordering
• Regulatory fines due to noncompliance.

the list could go on and on, these bullets are to give you a sense for the need to better manage data!

Marcel Proust on Discovery/Innovation

2009-07-01T13:42:00.000-07:00

"The only real voyage of discovery consists not in seeking new landscapes but in having new eyes"

Do you see opportunities where others don't? Do you know where to look for new ideas?

On a personal note, I have found that this approach of "fresh eyes" is very useful!

What is Product Data Management? Part 1.

2009-06-30T15:13:00.000-07:00

Product data management (PDM) is the use of software tools to track and control data related to a particular product. The data tracked usually involves the technical specifications of the product, specifications for manufacture and development, and the types of materials that will be required to produce the good.
History:
PDM was an offshoot of the engineering design activities that created product drawings, schematics and specification using CAD tools and paper drawings/documents.
Capabilities:
The need to control documentation evolved into key capabilities including the following core requirements.
(1) version control:
the ability to clearly distinguish changes as engineer’s progress through the design.
(2) Access control:
The ability to lock down components, assemblies, documents based on rights and rules defined by management. For example, component libraries should be maintained by the administrator or component librarian to ensure that standards are maintained.
(3) Collaboration:
The ability to have multiple users work on the same product structure. Most PDM systems have check-in / check-out capability which locks the objects to prevent loss of work and inadvertent over-writes.
(4) Product Structure
The product structure provides a hierarchical classification of the items which form a product. With the product structure, the understanding of the components which compose a product as well as their attributes, can be represented. The product structure shows the material, component parts subassemblies and other items in a hierarchical structure that represents the grouping of items on an assembly drawing or the grouping of items that come together at a stage in the manufacturing process.

Technorati Profile: e8krhy3qms

What is Data Management?

2009-06-30T13:02:00.000-07:00

There are two popular definitions:
One from DAMA
“Data Resource Management is the development and execution of architectures, policies, practices and procedures that properly manage the full data lifecycle needs of an enterprise”
Another from DMBOK
“Data management is the development, execution and supervision of plans, policies, programs and practices that control, protect, deliver and enhance the value of data and information assets.”
Companies of all size have to manage their data in order to meet their customer’s requirements in a timely manner.

Industry specific definitions

In the medical and pharmaceutical communities, Data Management is a term generally used to describe analysis of database information which has been collected during clinical trials. It also is used to define how data is identified, collected, and analyzed to establish clear evidence of outcomes.
In the modeling and simulation world, Data Management is described as "model-based", and is defined as planning organizing, and managing of data by defining and using rules, methods, tools, and respective resources to identify, clarify, define, and standardize the meaning of data as pertains to relationships.
In the information technology arena, DM is defined as a type of client/server computing where some portion of the application data is executed on two or more computers. It is also described in its IT application as control of data handling operations – such as acquisition, analysis, translation, coding, storage, retrieval, and distribution of data – but not necessarily the generation and use of data.

Data vs Information

2009-06-30T12:54:00.000-07:00

Data are plain facts. The word “data” is plural for “datum.” When data are processed, organized, structured or presented in a given context so as to make them useful, they are called Information.
It is not enough to have data (such as statistics on the economy). Data themselves are fairly useless. But when these data are interpreted and processed to determine its true meaning, they becomes useful and can be called Information.
Example:
Data is what you collect, for example you may collect a sample of heights, ages, genders within a given geographic area.
Information is what you extract from that, i.e.: average height by age, or average age by postcode.

Data Management is a critical part of business strategy as it is responsible for the transformation process of data into information. Information is the lifeblood of a business; its health is vital to an organization and is fundamental to your success and competitive edge. Good information reduces uncertainty surrounding decision making, and contributes to aspects such as improved productivity, compliance, and more focused marketing and customer loyalty.

Problem solving 101, Part 3.

2009-06-29T12:50:00.000-07:00

Cause and Effect Diagrams were developed by Kauro Ishikawa of Tokyo University in 1943. Cause-and-effect diagrams or fish bone are used to list the many and varied causes that can be attributed to a problem. These diagrams can help identify the reasons why a process is not performing as intended or hoped.
Cause and Effect Diagrams help you to think through causes of a problem thoroughly. Cause and Effect Diagrams are also known as fish bone Diagrams, because a completed diagram can look like the skeleton of a fish.
How to Use the Tool:
Follow these steps to solve a problem with a Cause and Effect Diagram:
Identify the problem:
Write down the exact problem you face in detail. Where appropriate identify who is involved, what the problem is, and when and where it occurs. Write the problem in a box on the left hand side of a large sheet of paper. Draw a line across the paper horizontally from the box. This arrangement, looking like the head and spine of a fish, gives you space to develop ideas.
Work out the major factors involved:
Next identify the factors that may contribute to the problem. Draw lines off the spine for each factor, and label it. These may be people involved with the problem, systems, equipment, materials, external forces, etc. Try to draw out as many possible factors as possible. If you are trying to solve the problem as part of a group, then this may be a good time for some brainstorming. Using the ‘Fish bone’ analogy, the factors you find can be thought of as the bones of the fish.
Identify possible causes:
For each of the factors you considered in stage 2, brainstorm possible causes of the problem that may be related to the factor. Show these as smaller lines coming off the ‘bones’ of the fish. Where a cause is large or complex, then it may be best to break the it down into sub-causes. Show these as lines coming off each cause line.
Analyze your diagram:
By this stage you should have a diagram showing all the possible causes of your problem that you can think of. Depending on the complexity and importance of the problem, you can now investigate the most likely causes further. This may involve setting up investigations, carrying out surveys, etc. These will be designed to test whether your assessments are correct.
Strengths
Rigorous analysis which overlooks no possible problem source
creates an easy to understand visual representation of the causes, categories of causes, and the problem statement
Weakness
The simplicity of a fishbone diagram can be both its strength and its weakness. As a weakness, the simplicity of the fishbone diagram may make it difficult to represent the truly interrelated nature of problems and causes in some very complex situations.

Leading Change. Part 1

2009-06-29T09:15:00.000-07:00

First step in becoming a successful change leader is to fully understanding your organization and matching the initiative to your organization’s real needs. This means not just adopting the latest management fad or implementing solutions for the sake of implementing new and emerging technologies.

Recognize that bringing about useful and meaningful change is fundamentally about changing people’s behavior. It is not primarily about installing a new system or business process. If people in the end do not behave and work differently, then the money and time spent in “doing stuff” is wasted.

How do you go about becoming a change leader?

(1) Focus on needs of the business. Understand the business (environment, business processes, business strategy, business needs (current and long term). Don’t assume anything, especially when considering technological solutions.
a. Is your proposed change important to the organization?
b. Why is it important?
c. How does it support the strategy?
d. What are the benefits? ROI
e. What is the cost impact? From an implementation perspective as well as from impact to resources, training, time to come up to speed and execution to previous levels
Help the business to succeed

(2) Focus on alignment: Competing messages from the people at the top is the kiss of death for a change initiative. Important change initiatives will always cross the boundaries of groups, departments, and divisions. Creating and sustaining agreement among key leaders may be one of the most important factors for successful change
Help the leaders manage their business, ensure that they are successful

(3) Focus on stakeholders. The stakeholders are the resources who will have to adopt and execute the change.
Don’t underestimate stakeholder management! Socialize the idea first, gain their acceptance and then engage them throughout your project from requirements gathering, design of business process/systems, get ideas on how they could make your change better, training needs, method for delivering training etc. this engagement will ensure that they feel that they are the customer and that this change will indeed help improve their day to day functions.
Help the organization (resources) to succeed

Problem solving 101, Part 2.

2009-06-26T15:40:00.000-07:00

In early 1990’s Ford Motor Company introduced a standardized set of steps to be followed in solving problems by quality improvement teams within the company. These eight step process of problem solving is known as 8D (Eight disciplines). It is the basis for all subsequent problem solving technique developments such as 6D, 7D, 9D and 10d.
The 8D is a methodology for product and process improvement, with an emphasis on team synergy.
The 8 steps are
D1. Establish the Team. Assemble a cross-functional team that has the knowledge, time, authority and skill to solve the problem and implement corrective actions. And set the structure, goals, roles, procedures and relationships to establish an effective team.
D2. Describe the Problem. Define the problem in measurable terms. Specify the internal or external customer problem by describing it in specific, quantifiable terms: Who, What, When, Where, Why, How, How many.
D3. Implement Containment Actions. Define and implement those intermediate actions that will protect any customer from the problem until permanent corrective action is implemented. Verify the effectiveness of the containment actions with data.
D4. Identify and Verify Root Causes. Identify all potential causes that could explain why the problem occurred. Test each potential cause against the problem description and data.
D5. Choose and Verify Corrective Actions. Confirm that the selected corrective actions will resolve the problem for the customer and will not cause undesirable side effects.
D6. Implement and Validate Permanent Corrective Actions. Choose ongoing controls to ensure the root cause is eliminated.
D7. Prevent Recurrence. Identify and implement steps that need to be taken to prevent the same or a similar problem from occurring in the future:
D8. Congratulate the Team. Recognize the collective efforts of your team. Publicize your achievement. Share your knowledge and learning throughout the organization
Strengths
• Effective approach at finding a root cause, developing proper actions to eliminate root causes, and implementing the permanent corrective action.
Weakness
• 8D training can be time consuming and difficult to develop.
Usage
• Major non-conformances
• Customer complaints
• Reoccurring issues

Problem solving 101, Part 1.

2009-06-26T11:26:00.000-07:00

The first step in problem solving is to understand the symptoms and then try to identify the root cause. There are many methodologies widely used. The “5 Whys” method is a simple method and can be effective in most cases.

For most problems, we can get to the root cause by drilling into proposed explanations by repeatedly asking "Why?" The 5 Whys method was developed by the Toyota Motor Corporation. It is based on the observation that five iterations of asking "Why?" is usually enough to get to the root cause of most real world problems.
Example
The following example demonstrates the basic process: My car will not start. (the problem)
Why? - The battery is dead. (first why)
Why? - The alternator is not functioning. (second why)
Why? - The alternator belt has broken. (third why)
Why? - The alternator belt was well beyond its useful service life and has never been replaced. (fourth why)
Why? - I have not been maintaining my car according to the recommended service schedule. (fifth why, root cause)

Strengths
1. It helps to quickly determine the root cause of a problem
2. It is easy to learn and apply

Weakness
1. The results are not repeatable. We may well end up with different results depending on who runs the exercise.
2. Inability to go beyond the investigator's current knowledge - can't find causes that they don't already know

Getting to the true root cause can be tricky to a beginner! but continued practice of this exercise help. Don't stop at the first or second simple answer, or be blinded by the symptoms or settle for the first ‘apparent’ cause. The first ‘cause’ offered is almost never the real root cause.

Even though this method was popularized by Toyota, this method of inquiry has been around for ages. I remember a poem/song my wife sings to our son.

For want of a nail a shoe was lost,
for want of a shoe a horse was lost,
for want of a horse a rider was lost,
for want of a rider an army was lost,
for want of an army a battle was lost,
for want of a battle the war was lost,
for want of the war the kingdom was lost,

Debate: Six Sigma vs. Innovation

2009-06-25T09:43:00.000-07:00

I recently came across an article on business week about the debate over if six sigma stifles innovation.

The key takeaways for me from this article was
(1) Six Sigma is designed to inject more efficiency and productivity into a company's systems
(2) Disruptive innovation is going to be more entrepreneurial.
(3) smart companies separate the efforts at innovation from ongoing efforts at continuous improvement
(4) if managed properly, Six Sigma and innovation can go hand in hand

This got me thinking about my past experience, when I played an active role in facilitating product development and worked very closely with engineering. We had established processes for products which were in beta or production life cycle stage. Process adherence was essential as the tools and systems were shipped to customers when they reached this level of maturity.

By impeding new product introduction with rules did increase cycle times and caused endless frustration. So we came up with a solution, to allow engineering more freedom and flexibility in creating parts and bill of material structure with minimal requirements. We did ensure that certain checks and balances were in place so as to ensure proper procurement using revision control. Fast track changes with minimal approval cycles were also of great value.

In an organizational development activity, we studied profiles of leaders and managers. A similar issue was raised about leadership without management.

We should allow flexibility to encourage an entrepreneurial spirit with minimal guidelines!

Continuous improvement Vs Continual improvement

2009-06-24T10:01:00.000-07:00

"Continuous improvement" and "Continual improvement" are used interchangeably and shouldn't be used in that manner!. There is a difference. Let us start by analyzing the semantics of these words.

Continuous indicates duration without interruption.
Continual indicates duration that continues over a long period of time, but with intervals of interruption.

Continuous improvement means that organizations are in a constant state of driving process improvements. This involves a focus on linear and incremental improvement within existing processes.
Continual improvements means that organizations go through process improvements in stages and these stages are separated by a period of time. This period of time might be necessary to understand if the improvements did actually help the bottom line! In some cases, the results might take a while to come to fruition.

After researching this, I have found that the usage of these terms is very loose and interchangeably…A number of authors have recently published their opinions indicating that continual improvement is of a broader scope than continuous improvement.
I agree with their sentiment and in my opinion, it is best to focus on continual improvement and ensure that learning is captured through effective knowledge management.

Process Improvement Methodologies.

2009-06-23T08:36:00.000-07:00

From my research into methodologies I have found that the two most popular methods are (1) PDCA and (2) DMAIC.

PDCA ("Plan-Do-Check-Act") is an iterative four-step problem-solving process typically used in business process improvement. PDCA was made popular by Dr. W. Edwards Deming, who is considered by many to be the father of modern quality control;
Plan – What are you going to do?
Do – Based on analysis, decide on solution.
Check – Verify the solution worked.
Act – Standardize and decide on next PDCA step.
When you are done with PDCA, you do it again. Or, in other words, you are never done because you must practice continuous quality improvements.

DMAIC ("Define-Measure-Analyze-Improve-Control")is a five step process involving the following steps. DMAIC is one of the two key method used in Six Sigma (business management strategy, initially implemented by Motorola).
Define high-level project goals and the current process.
Measure key aspects of the current process and collect relevant data.
Analyze the data to verify cause-and-effect relationships. Determine what the relationships are, and attempt to ensure that all factors have been considered.
Improve or optimize the process based upon data analysis using techniques like Design of experiments.
Control to ensure that any deviations from target are corrected before they result in defects.

PDCA and DMAIC are very similar, but have some differences. PDCA emphasizes more the need to repeat the steps, while DMAIC adds the Control step lacking in PDCA.

Technorati Profile: e8krhy3qms

Metrics!

2009-06-22T10:16:00.000-07:00

What is a metric?
A metric is essentially a clear, quantitative, objective measure to assess performance or progress towards a goal.

Metrics can identify important events and trends in the organization and can help guide the organization toward informed decisions.

Every metric will affect actions and decisions.

Guidelines for developing metrics: Metrics and measurements should indicate the ability to meet established business goals (customer satisfaction, cost reduction, improved quality, productivity and cycle time)
1. Ensure that the metrics are SMART (Specific, Measurable, Attainable, Relevant, and Time bound)
2. Ensure that the metrics are relevant to the business goals
3. Ensure that the metrics are clearly grouped together to indicate the value for e.g. performance to business goals
4. Include past performance to indicate how today compares to the past
5. Keep it simple
6. The metrics should be able to tell the story!

Metrics: Effectivess Versus Efficiency

2009-06-22T09:00:00.000-07:00

Before you go through improving processes, try and understand how the process is working today.

How do you know if the process is working? Try and get to know how the process is measured and analyzed. What are the metrics? Are these metrics related to Effectiveness or are they related to Efficiency?

Are they these the same? No

Effectiveness means that the job was done correctly. Whereas, efficiency means that the job was accomplished on time.

Another way to look at it...you hire a data entry person who has to enter data into multiple spreadsheets/data systems. How do you know if this person is working properly and is doing the job you hired them for?

(1) Did you have to correct the data? If yes how many times did you do so? Effectiveness.
(2) Did the person complete the activity within the time allocated? Efficiency.

Each and every process should ideally have measurement of effectiveness and efficiency. If these metrics don’t exist; Work with management, key stakeholders, process owners and the worker bees to define these.

Don’t stop here, having measurements/metrics doesn't mean everyone will adhere to these. In order to ensure adherence to standards, you will need a governance/accountability system.