Implementing Business Process Management: Five Not-So-Easy Pieces

A nice common-sense summary of 5 factors, one or more of which "almost always" causes "failure to achieve results after attempting to implement a business process management (BPM) initiative":

Implementing Business Process Management: Five Not-So-Easy Pieces

My favorite (and the factor which I have noticed most often is the true culprit when these types of process improvement initiatives fail), is the last of the 5 items:

"5. Either shortchanging, or entirely skipping, the all-important task of documenting and analyzing the AS-IS process before designing the TO-BE process. I touched upon this in Reason No. 1, but it deserves its own bullet, because most enterprises have never fully documented their current processes. Typically, many things are done on a daily basis simply because that’s the way they’ve always been done. But without capturing and understanding the “why” for each of these, you are flying blind in determining what your future processes should look like. And take due caution regarding your new path: Often, as we fix one problem, we create another. Even if you’re clear on where you want to go, you need to know where you are to determine the best route."

A Pragmatist's Guide to Structuring IT Asset Data, Scott Parkin, eWeek, 2008-01-18

A nice article describing the real-world ILM challenges for IT asset management. The ITSM benefits of of linking the asset's service-incident history to the incident-management system, including hard and soft costs per outage, seem significant. However, this does not seem common among the vast majority of the COTS helpdesk systems I have seen over the years, and certainly not among the Service Management modules of major ERP systems, let alone with integrated continuous auto-discovery/maintenance of all hardware and software assets found on the network... sigh....

Here is a snippet from the full eWeek article :

"... Track initial acquisition costs, including asset purchase, required peripheral or supporting devices, operating system and software (as needed), and service contracts:

Most of this data will come from purchase orders; some will need to be calculated as a pro-rata share of a bulk purchase or license agreement.

For new purchases, update your purchasing process to include calculating and tracking this data in your asset record; for existing assets you will need to create a project to go back and aggregate/calculate this information and add it to your asset records.

Track ongoing maintenance costs, including annual service contracts, upgrade or replacement parts and the costs associated with Service Desk incidents for each device.
Ideally, this information is collected at the time of purchase or service and is immediately attached to the asset's service history record as a function of your established process. You should update your Incident management process to support this, whether you update the asset record manually or through automated technology.
This can be the single most daunting task in the mix; extracting and aggregating historical data for existing assets is a gargantuan task. Many organizations choose to simply start tracking this data as of a specific date and leave existing data unstructured. This is a good method for those organizations that are resource-constrained and willing to wait for highly qualified data.
Identify replacement costs for hardware, software and infrastructure elements. Remember to include both disposal costs for existing assets and install/deployment costs for new assets.
For commodity items such as end-user hardware (desktop, laptop) and software, these costs should be predictable within a range and will tend to be updated once a year as new contracts are negotiated.
For high-impact or high-value items, the cost of purchase may only be a small part of the total costs, and those costs may be difficult to estimate. This data is intended for planning purposes and should be reviewed at the time of planning, so supply a best estimate with supporting documentation to be used as a starting point for further research, not as an authoritative declaration.
The key benefit here is being able to quickly view approximate costs for individual assets, to aggregate that data by department or cost center and to use that data in research and planning efforts...."

Salesforce, SAP Battle for On-Demand Supremacy

SAP attempts to address the SaaS and the Web 2.0 expectations of the user community, with its announcement regarding "Business ByDesign":

Salesforce, SAP Battle for On-Demand Supremacy:
"...Salesforce.com officials announced the final piece of the platform, Visualforce, which lets developers build any user interface to any application.

The San Francisco-based company also announced two new applications, Content and Ideas, that add to its CRM portfolio but appeal to a broad user base that could span departments.

Content provides a raft of Web 2.0 technologies—such as tagging, subscriptions, recommendations—that help users manage unstructured data. Ideas is a service that enables companies to build communities where participants can post and vote on ideas.

By contrast, SAP, based in Walldorf, Germany, has taken the fully integrated ERP route when it comes to on-demand.

SAP's newly launched—though not yet available—Business ByDesign offering provides suites for common back-office functions like finance, human resources, CRM, supply chain management, supplier relationship management and corporate governance.

The suite provides the all-important integration with Microsoft's Office environment, and provides newer Enterprise 2.0 technologies like on-demand community interaction and live help links from within the Business ByDesign suite..."

Total cost study for an open source ERP project

Interesting way to think about COTS vs. OpenSource for ERP (thanks to The Enterprise System Spectator for this and for pointing to the original Baseline Magazine study)

The Enterprise System Spectator: Total cost study for an open source ERP project: "...Open source is moving up the technology stack to business applications. Whether it can gain significant market share remains to be seen. ERP systems are much more specialized than operating systems and application platforms. It is not clear to me whether there are sufficient populations of developers to gain critical mass for these products, as there has been for products lower in the stack. Who should consider open source ERP today? In my opinion, these solutions today are not so much an alternative to proprietary software as they are to custom development. An organization that knows it will need to do significant customization or enhancements to an ERP system should consider open source as a starting point instead of proprietary ERP. Organizations with unique requirements or unusual business models may be in this category. Modifying core code of a proprietary ERP system generally voids the warranty and makes on-going support less relevant, since the vendor will not support your custom modifications. Why not start, then, with open source ERP, where there is little if any charge for the source code? To me, that's a better choice than to start with 100% custom development. I'm looking for more cost metrics on open source ERP implementations. If you're willing to share them with me, let me know..."

Oracle and SAP passed over for IFS by water desalination firm

Oracle and SAP passed over for IFS by water desalination firm:

... Seven Seas, which was founded late last year, is in the business of acquiring and building plants that make ocean saltwater suitable for drinking. The growing company, which serves resorts, municipalities and other commercial water users in the Caribbean, says that Oracle's and SAP's respective ERP offerings are simply too big and complicated.

Instead, Seven Seas chose a smaller ERP vendor, IFS AB, to manage the general ledger, project management and field services operations at its various facilities.

'I've had exposure to SAP as well as Oracle and basically we chose not to consider those two solutions just based on our prior experience and on the complexity of the implementations that we've experienced,' said John Curtis, Seven Seas' CEO. 'Oracle was the better of those two. [But] the team's conclusion very quickly and very clearly dictated going for a more user-friendly version and something that better fit our business model.'..."

Microsoft Reaches ERP Milestone

Microsoft Reaches ERP Milestone: "Microsoft has reached the halfway point in its three-year march to converge four enterprise resource planning suites into a common technology platform.
ADVERTISEMENT

But it's still an open question whether the campaign will deliver a fully converged suite that will hold its own in the midmarket that SAP and Oracle also covet, and whether customers still care...

Project Green, the early code name for the suite's convergence, was originally a two-step plan to rewrite Microsoft's four ERP suites—GP, NAV, SL and AX—into a single code base.

But at their Convergence user conference in March, Microsoft officials confirmed that the company will likely not move to a single code base but, rather, converge the suites through a common underlying technology stack, including SQL Server, Visual Studio .Net, BizTalk Server and Workflow Foundation..."

SAP Roadmap: SAP Pushes SOA, On Demand

SAP Pushes SOA, On Demand: "... where SAP may be leading the pack in establishing NetWeaver, its services-based platform and ERP (enterprise resource planning) application suite, it's lacking in the fundamental resources needed to carry the SOA mission forward: a skilled work force to help convert users from older R/3-based systems to the newer SAP ERP 6.0 suite and a user community ready to fully embrace the concepts of SOA, industry observers said.
[SOA] is not the magic bullet to solve all problems,' said Harry Bruce, section IT manager at Procter & Gamble, in Cincinnati. "