The market for business intelligence (BI) tools in the Asia-Pacific region, excluding Japan, grew 7.7 percent in 2008 to an estimated US$445.3 million… full article…
Archive for May, 2009
Hard times boost demand for intelligence
Wednesday, May 27th, 2009Data Integrity – How is this really achieved?
Thursday, May 21st, 2009Data integrity is the assurance that data is consistent and correct. Spare parts, sounds fairly simple?
What are the basic elements of a part record; name, part number, description? Data Integrity is used way too much but is a very vague concept. Let’s just look at the purchasing department; it is easy if the part records are only used by the purchasing department where the main objective is to purchase the item. This example is all the data that the buyer will need to purchase this switch.
How would a buyer know that these are the same parts? Two different manufacturer names and two different part numbers; this scenario will cause duplication in a purchasing system. The result is the additional work of creating and maintaining two contracts but also cause downstream effects such as excess inventory with more than 1 stocking location, lack of a volume purchase or a global view.
Question: Is the answer to always to confirm the actual manufacturer and set up supplier references?
Software as a Service (SaaS)
Tuesday, May 19th, 2009Is SaaS a realistic IT solution for the global manufacturer?
Yes.
I was first going to define what Software as a Service actually is. When I tried to find a clear concise definition I had trouble finding one covering all the possible deployment, payment, and support models.
This is what I came up with:
Software as a Service – A software application that is available exclusively for use through a web browser, paid for using a pre-determined payment schedule based on predefined usage metrics negotiated with the SaaS provider, and supported by an entity that is not the end user or end business unit within an organization (regardless of where data is physically stored).
This is the Wikipedia entry for Software as a service.
This is what Oracle has determined SaaS to be.
Here is what PC Magazine has determined SaaS to be.
I encourage you to form your own definition and let me know what you come up with.
The major issues that have been communicated to me as reasons why manufacturing IT executives are hesitant or completely unwilling to place their priceless data inside an application almost completely under the control of a third party are as follows:
- Security is by far the greatest concern, and it should be high on the list, it feels like almost monthly we hear about another data base breach at a major credit card processing firm or student medical information stolen from a university data center (Hackers steal UC Berkeley health records). Unless you as an IT executive are confident your organization has security measures that are far superior to those commercially available, security should be knocked further down the list of concerns. We have all been using SaaS for many years to facilitate the business of moving actual money for years. Can you name a bank or Fortune 1000 manufacturer that does not use some sort of electronic tool to transfer money or process payments? The issue of security as related to SaaS should be thought of on a case by case scenario addressed individually with each provider you are considering sourcing your software from. This should be done before any contract is awarded prior to any data being placed on infrastructure outside your control.
- Availability aka uptime is also a major concern. If the data is not accessible all the time how can the business run? The answer to that is determined by the criticality of the data. You would be hard pressed to find an internally hosted application that has not experienced some sort of downtime, especially when you consider the volume of patching Microsoft performs. Aside from natural disasters or area wide network outages, downtime can be addressed through proper planning and effective communication between the service provider and the customer base.
- Cost cutting on hardware . . . Depending on the type of master data being stored and the data model being used to store it there are many options for hardware configuration. Options like dedicated vs. shared server hosting models can be a huge factor in determining the cost to maintain a hosted SaaS solution. If the data is financial in type, then most certainly dedicated hardware should be used. On the other side of the servers if you are storing data like spare part information, most likely available without so much as configuring a password, why not utilize the cloud. When a hosted SaaS solution is implemented hardware, support, hosting is all moved into a usually reasonably low monthly payment.
Yes. If properly planned and properly implemented software as a service is a realistic solution to alleviate many issues with internally hosted and maintained applications.
Consultant: Master Data Management Can Pay off During M&As
Friday, May 15th, 2009
Master data management initiatives are known for being expensive and cumbersome. In fact, it looks like exactly the sort of project you would want to avoid if… Read More
Why MDM Initiatives Fail
Tuesday, May 5th, 2009I talk with manufacturing executives every day who tell me story after story about failed MDM projects. By MDM I’m referring to Master Data Management. In most cases these executives were trying to consolidate and purify database records consisting of parts and materials information as well as OEM and supplier data. The companies these executives work for have invested hundreds of thousands of dollars, in some case millions of dollars, on software implementations that are supposed to solve their MDM problems. SAP, Oracle, IBM, all have sophisticated MDM applications that cost ungodly amounts of money and in many cases, make the problems worse.
Don’t get me wrong, SAP, Oracle, IBM, even Microsoft are the most innovative software companies on earth. The predicament is MDM is not a problem that software alone can solve. MDM is inherently a people and a cultural problem first, a software problem second. Several people and cultural factors must be considered before software can be applied to the solution.
The people part revolves around which users in your company touch the data. Typically there are thousands of users touching MRO data. Which users enter the data originally? Which users are permitted to manipulate or even delete the data? Which users rely on the accuracy of that data to perform their daily jobs as effectively as possible?
The cultural part revolves around policies and procedures, ownership of the data, and data governance. What are the policies and procedures in place ensuring users enter data correctly? Who owns the data and is responsible for enforcing those policies and procedures? Most importantly, are people required to use that data to make decisions, such as costly purchases or to perform critical MRO functions?
By answering the questions above and building cross-functional teams enabling the organization to truly understand the full scope of the MDM problem, then, and only then, can intelligent software and technology decisions be made. The core of the problem is that as companies keep spending money on software, but invest little if anything to ensure the data used by that software is correct to begin with and then validated on an ongoing basis.
The reality is people problems are solved by people and then technology. Cultural problems must be resolved by building cultural change strategies, and then by using technology to enforce the strategy.
Are you throwing software at people and cultural problems?
Language Fonts
Tuesday, May 5th, 2009I had the fortunate opportunity to participate in a large data migration, and over the next couple of weeks as I run through my lessons learned, I will update my blog.
Language Font Lessons:
As a data migration plan is put in place to confirm that data has migrated accurately to a new system, audits and verification processes are planned, counting the data base rows, and verifying that tables are populated, etc. Yet in this data we sometimes find question marks or squares indicating that the method used to transfer data did not migrate some of the special characters in a number of different languages . . . . and a Unit of Measure that appears as a question mark will create a multiple number of issues for the purchasing process.
The solution is that the verification process should be designed to include the users of the data to confirm migration. The migration cannot be planned from only an IT or Software Suppliers’ perspective. I find that the SME, aware of all aspects of “their” data needs to participate in the review and confirm the migration success based on data quality.
Before or After Headache Business Decisions
Tuesday, May 5th, 2009Business Intelligence, we all hear the words. We all want it. Some of the executives and manufacturing managers reading this even think that they are using it. Are they really? You are probably thinking . . . Yes, I am. I frequently receive reports detailing maintenance activities in my facilities. These reports probably include spare part usage statistics of some sort, down time calculations and associated dollar loss figures, critical inventory level flags, along with 30 data fields you probably don’t use to run your business. These reports are most likely delivered and viewed in Microsoft Excel or other available spreadsheet programs. Before the business/process champion or the person(s) otherwise responsible to put this information to use receives the report it is most likely generated and formatted by an analyst of sorts.
The problem? . . . you are probably asking. The problem is that the reporting and analyzing process to attain the intelligence information all happens after the fact. The spare part has already failed, the maintenance person responsible has already been to spare storage and realized that the critical spare is not stocked, the purchasing rep has already issued a PO to a local supplier for a much higher dollar amount than warranted by the contract with the actual manufacturer and the business intelligence as you call it, happens only after all of this has occurred. This is NOT business intelligence; it is simply and only historical information.
In better fiscal times, these issues weren’t a problem any part of the organization wanted to tackle. We all had large staffs of highly trained and experienced MRO professionals, who knew their manufacturing facilities like their own home. Cars, boats, planes, bicycles, mp3 players and consumer goods of all types were all flying off the shelf at records numbers. Margins were high, and there may not have been enough pressure (bottom up/ or top down) to make a large capital investment in an enterprise class business (manufacturing) intelligence platform. Things have all changed; resources across the board have been slashed faster and wider than ever in the last 2 decades. Is your organization prepared for the coming era?
This may seem like random rambling . . . I have a point.
We all have MRO information, master data, and historical statistics. All of which is only information, raw data until it is put to use in the right manner. The key to the usage of this information is foresight. The information needs to be gathered, analyzed, and most importantly disseminated in real time to the people who need it to make REAL TIME business decisions.
Over the next several years I see more and more pressure put on IT and business process leaders to put in place solutions that can aid in making real time decisions before the problems happen.
Are your manufacturing/business decisions made after the headaches or before?
CR