Last year I wrote about the problem with the billing system that Johannesburg City Council had implemented. The project, a SAP-based implementation internally called Project Phakama, is in the news again for all the wrong reasons. According to one report, the project has cost the City over R800 million (over $100 million). The situation has reached such a bad state again that there was a report that central government was considering stepping in.
This is obviously a highly strategic and visible project, and it’s not uncommon for these kind of ‘heroic’ projects to have very public bugs. As I mentioned in my previous blog about this project, SAP had won a quality award for it, but has readers of Michael Krigsman’s Project Failure blog will know, the software is only one part of the issue.
In the ‘Billing Crisis’ news report, an opposition spokesman says the problem is that it is a complex system
“…and people have not been properly trained for the system”.
‘The city’s head of finance, Parks Tau, said implementation of the IT project had been completed and that problems with it were “interface-related”.’
So here we have two issues which need to be addressed – people-related, and external systems.
On the one hand, the project owners (City officials) seem to be saying that the project is nearly done. On the other, they don’t appear to have the complex IT project experience to know “What ‘Done’ Looks Like”, to use Glen Alleman’s phrase.
SAP is fortunate that it is not their name that is being publicly criticised, as has happened in other municipal projects.
One thing I am glad about – that I am not the vendor or implementation partner project manager on that project.
Update #1: SAP have distanced themselves from the project – ‘Don’t blame us‘
Update #2: The story behind the project chaos is revealed – The connections that disconnected Joburg
I saw a short news article (registration required) that Microsoft’s Dynamics AX (the old Axapta) could now provide integration of documents between AX and SAP (the Microsoft press release is here). My initial thought was “what’s so special about that”, until it dawned on me that some people think SAP integration requires something magical. Granted, SAP is not the easiest application to work with, but it does have integration hooks – Netweaver being one.
If you are not sure why SAP integration is needed, the reason is that many large national and mega international corporates run SAP at the head office or for large divisions, but they don’t necessarily run SAP everywhere. There are large multi-national companies which uses SAP in their main offices, but the dozens of smaller divisions don’t run SAP, they use SYSPRO. Why? Because SAP is so complex and expensive it makes no business sense for a smaller organisation to use it, but SYSPRO provides all the functionality they need (for distribution and manufacturing) at a much lower cost and far less complexity. Analyst R ‘Ray’ Wang has discussed in more the ERP needs of small and medium businesses (SMBs) and when companies should have a two-tier ERP strategy.
Microsoft will try to sell you their Biztalk product to help the process. However, Biztalk is costly and adds another layer of technological complexity to the integration issue. If you run SYSPRO you don’t need Biztalk for SAP integration.
SYSPRO solved the problem a long time ago when it introduced its e.net integration software and a feature called Document Flow Manager (DFM). SYSPRO e.net solutions (the proper name of the product) is a set of components that enables access to SYSPRO business logic and data without using the SYSPRO client interface; it was one of the first applications to take advantage of Microsoft .NET Framework for interoperability and application integration. The DFM module consists of a group of services that:
- poll a data location (ie, folder) looking for files (documents), or for incoming email looking for particular attachments,
- compare documents against specified ‘contracts’ for a match,
- places the matched documents in a message queue,
- processes the message queue and applies an appropriate SYSPRO business object to process the document and return a result
The contracts can be configured to specify file types that must be located and which SYSPRO e.net business objects must operate on the files.
Incoming documents do not need to be in XML format. A contract can specify pre-processing using XSLT (Extensible Stylesheet Language Transformations), an XML-based language used for the transformation of documents into XML documents. The same process can be applied in reverse to ongoing documents.
You will need .Net Framework and a few other bits of Microsoft software (such as MS Message Queue), but they are essentially “free features” available in Windows.
While the skilled work is in setting up the XSLT transform and configuring the contracts, the important work is getting suppliers or customers to agree to using electronic document processing and a standard for the documents. Ten years ago, some vendors started talking about inter-company transaction processing using integration software. Now the reality is here and the functionality is available. Remember, SAP integration is not difficult if you have the right technology and, of course, the budget and commitment to do it.
Are you considering a more cost-effective ERP for parts of your organisation but worrying how to link to the head office SAP system? Have you been told you need Biztalk, or some other costly specialised software, to allow you to transact and operate electronically with partners or larger divisions? Have you looked at SYSPRO? I would be interested to hear your comments.
If this was somewhere in Europe or the US, the international commentators would be all over it, but as it’s Africa only those of us living here are the ones making a fuss. I am talking about the Johannesburg City Council’s SAP-based billing system, Programme Phakama, and the point in question is how do you define project success or failure, something that Michael Krigsman covers frequently.
The goals of the Phakama programme were to centralise the city’s billing databases and replace multiple, disparate IT systems, in order to improve accuracy and completeness of the billing and invoicing process, and improve levels of collection and client service. Land information systems would also be integrated into the billing system, allowing the city to bill residents according to the correct valuation and usage - Joburg promises billing progress.
At the end of June, the city council announced that it had been awarded a SAP Quality Award for the successful implementation of the programme. The problem is that only the city council seems to believe this has been a successful project. Earlier this year, problems were being reported about the ERP implementation. When SAP was questioned about the award, the response was that the city “was nominated because of its clear governance policy and for implementing the project on time. It competed against 19 other companies in Africa for this award.”
That sounds to me like the criteria for project success were based primarily on budget and on-time measures, and that other issues around data quality and customer service were not really considered.
According the online article, SAP fails to explain award, opposition councilors “find it difficult to understand how the system picked up the award.” Since the end of July, there are have further articles on the problems resulting from the project, culminating in a recent article “Reputation suicide: SAP’s presentation of a Quality Award to the COJ’s billing system must mean it does not want to look like a high-standard, sane company anymore.”
South Africa has just completed a ‘really mega-project’ called FIFA 2010 South Africa, which 99.9% of people believe was highly successful and showed that we could deliver on all the important metrics – time, budget, quality, safety, service. It’s a pity that a project that affects thousands of people in Johannesburg did not have the same project management and oversight. There are similarities to Home Affairs IT project failure, and it leaves me concerned that management of major IT projects in South Africa does not show the same level of skill and attention that big projects like FIFA 2010 had.
On the other hand, big IT projects fail all over the world, as Michael Krigsman continually points out, so maybe we shouldn’t feel too bad.
ERP software is developed by very clever people, so you would think that they would have enough sense to make the application upgrade process straightforward.
A few years ago I managed a Microsoft Dynamics reseller group that did Navision (OK, I know Microsoft wants it called Dynamics NAV, but lots of people still use the old name). I was responsible sales, account management and project management, and got to learn about the hassles of ERP upgrades firsthand and repeatedly.
If you are a NAV customer who has customised their application, the process of upgrading involves:
- installing the new version of NAV without customisations
- migrating and testing each customisation separately
- final testing of the new version with customisations
- make the new version live
Step 2 can be a serious project phase if the customisations are numerous or complex. For a few of my NAV customers, it might have been cheaper to buy a new ERP than upgrade.
I saw this post from the Sapmesideways blog, detailing his ongoing SAP project, and was interested to read what it’s like trying to manage SAP software upgrades.
When I started selling SYSPRO 3 years ago, one of the things that really impressed me was how easy upgrades were (caveat: be on SYSPRO 6 and Windows). Again, I had firsthand experience of its relative simplicity in 2008. The customer is a large manufacturer with over 1000 employees, with multiple points of integration between SYSPRO and specialist third party applications, and with some serious customisation for its particular ETO type of business.
There was fairly thorough discussion and planning for the upgrade in the weeks leading to the event. The preparation for the upgrade started at the beginning of the week, but the actual upgrade process to SYSPRO 6 Service Pack 2 took one weekend. A significant part of that time was taken up by backing up and restoring the SQL Server transaction database. The upgrade was done by Sunday morning, and the rest of the weekend was used to test the application and the integration with other systems.
The most serious issue after the upgrade was training the accounting staff on a new A/P payment cycle that was introduced with SP2.
As SYSPRO moves towards the next major software release in May – SYSPRO 6.1 – the issue of upgrades comes up frequently. The beauty about SYSPRO is that any customisations done on the user or module side are carried through from the previous version 6 into 6.1. Interfacing between SYSPRO and other applications is done using SYSPRO’s e.net solutions, a Microsoft .NET-based integration layer, and that doesn’t change. So the integration with external applications doesn’t need to be re-developed.
Making upgrades easier is important for the market that SYSPRO addresses – the mid-market distribution and/or manufacturing organisation. IT resources, skills and budgets for these types of companies are limited, so having an ERP that actually reduces complexity should be a plus.
There used to be a TV advert for a South African bank that coined a phrase “Makes you think, doesn’t it?” Makes me wonder what other ERP applications have done the necessary work on their application internals to take the hard work out of upgrades?
If your company was looking for an ERP to help manage a manufacturing operation, which ERP vendors would you turn to for a solution? It seems that most large companies would include SAP on their selection list because SAP is the biggest. But biggest is not necessarily the best.
Recently we were called by one of our client’s competitors to discuss some possible custom development for their ERP system. Our client uses SYSPRO, the competitor (which is large) uses SAP. I had an opportunity to get some information on how the competitor was using SAP in their manufacturing environment. This company must be spending millions a year on SAP maintenance fees while not getting anywhere near the benefit that our client gets from SYSPRO.
I was talking with knowledgeable colleagues what reasons a business would choose SAP rather than SYSPRO:
- If you are in a couple of industry verticals, like financial services, in which SAP specialises.
- If you are in certain process manufacturing sectors, such as aluminium production, you might also be able to justify selecting SAP.
- If you are a global company needing to run separate local financial operations, and consolidate to regional and global operations, SAP’s financials are strong.
Apart from these three reasons, and if you are in manufacuting, there is absolutely no reason why SYSPRO shouldn’t be one of your short-listed ERP vendors. It amazes me therefore, in the current economic climate, that so many companies are still using SAP for their ERP and spending so much on SAP maintenance, rather than migrating to a more useful and cost-effective ERP solution.
From an SA online news article, SAP claims that its Kick Start and Go solution for SMEs can be implemented in two days; and its Fast Start pre-configured CRM, financials and hardware solution in 8 weeks.
Comment from a local SAP consultant is that it takes 2 days to configure SAP – so how does Kick Start and Go work? We are implementing at a large manufacturing company (target segment for the Fast Start program) and the complexity of an organisation like that makes an 8 week timetable look totally unrealistic.
I assume that SAP comes in and tells the company how its financials will be structured and how its processes will operate in future.
In July AMR Research reported that SAP had raised the maintenance fees of its enterprise suite to 22% of net licence value – in other words, SAP customers now pay the full cost of their software every five years. In a way that is great for competitors like SYSPRO who are charging 10-12 percent points less.
A recent blog on the IT Project Failures site says that the big ERP vendors are doing this because the complexity of their systems and their implementation puts the vendors in a position to abuse their customers.
If that attitude is correct then it disturbs me, as it reminds me of the phenomenon of the tragedy of the commons – by abusing their resources (customers) now those vendors risk destroying their own eco-system later.
For some time there has been a debate about whether the world is flat or spikey. This refers to whether globalisation has made everything uniform (flat) around the world, or whether there is still significant regional diversity (spikey).
A survey of the ERP market in South Africa seems to indicate to me that the world is definitely spikey. If the world was flat, I would have expected that the relative market shares of the major ERP players in the developed ‘north’ would be reflected in the SA market. But as the research found, that is not the case.
Looking at the SA mid-market (companies with 50 to 250 PCs, or 251 to 500 PCs), 35% of the survey were manufacturing companies; about 30% were in professional services, wholesale trade, and logistics; and rest in areas like construction, finance, mining, and parastatals. Over 50% of the survey were in the Gauteng province where Johannesburg is located. 70% of the respondents had between 50 and 250 PCs.
When it came to products, Microsoft Dynamics GP (ex Great Plains) and CRM had over 50% recognition; the other Dynamics products were not well known (NAV had some awareness but AX was very low).
What were the best known ERP brands? SAP (not surprisingly) and SYSPRO (SA’s own ERP) … by far. So much for the other big ERP players efforts in SA!
So when you read another press release from a large ERP vendor which describes them as “leading”, check which geographies they are referring to.
The survey also asked what factors made companies change their ERP, in order:
- greater functionality
- new business requirements
- company growth
- lower cost (note this)
- merger/acquisition with company with different ERP
What were the reasons for choosing an ERP, in order:
- good fit to business
- technical superiority/innovation
- ease of implementation
- low cost of ownership (note again)
The vendor selection criteria were:
- understand our business/industry
- customer service
- ease of implementation/doing business
For the ERP marketers, the major sources of ERP information were:
- search engines
- vendor/product websites
What had the biggest impact in creating awareness:
- customer reference
- technology/business events
- sales person visit