All entries for Sunday 10 February 2008

Software in the Enterprise

A while back when I first started work in the (c) “Real World”, I was surprised at some of the restrictions made on corporate computer use, for example users were not allowed use of Microsoft Access for reasons that I could not at the time comprehend. Now I’m working in an environment full of people using an Access Database for this and an Access Database for that, I now fully understand the need to prevent such custom systems wandering around a company. Put simply any time you have a custom system you end up with a group of people manually linking together many systems instead of relying on the corporate solution, for example SAP or another large ERP system. So what? So some companies use small systems manually linked while others use large homogeneous applications, what difference does it make? Well custom systems are so much easier to break than a corporate supported solution. If the person that created the system architecture moves on then it is less understood and when (not if) it breaks then it becomes that much harder to fix. Plus most custom solutions are based in Access or Excel and these are resolutely one user at a time tools. Whatever people say about Access being able to cope with up to ten users at a time, it’s simply not true because it’s wayyyyy too easy to corrupt the data. Excel sheets, though they can be shared between many users, don’t offer appropriate control either for the same reason. Many people in a company will email a “file” out to everyone, unaware of the logistical nightmare they are about to create when getting said file back. How do you know which version of the dozens you got back is the latest? Have they all had changes etc etc etc.

So what many companies do is implement a sensible strategy of centralised systems that all talk to each other appropriately. Of course the difficulty with any centralised solution is that with the number of users in an organisation, many have their own personal tweaks that make their job that bit easier, while central solutions have to cater to everyone. As a result companies like SAP make applications that allow people to customise the view of their data but not necessarily how it works. It doesn’t satisfy everyone and often they will use a few local sheets for their own use on the whole. If you like this is the “second” stage of three in the progress to good enterprise architecture.

1. In the first stage you have many custom systems all held together by people
2. In the second stage you have the centralised systems and a few custom parts around the edge, contributing to the whole
3. The third stage is the end goal, almost all of the data within a centralised system. That doesn’t mean there is no room for the local applications, the Word document associated with a job or the PDF preferably since they are a more open, continuous standard than the MS custom formats.

Reaching that third stage is very difficult, because of the number of different areas that must be covered. Of course in general terms you need to know what those are and broadly speaking many are similar for any company that deals with a physical object e.g. retail, manufacture, frieght haulage, transport etc. Requirements in some industries like Financial or other data based organisations would of course differ somewhat.

At the heart of the company you need a system to keep track of what is going where, in many cases this will be an ERP system such as SAP/ERP or Oracle Peoplesoft. These systems are the crucial to the overall running of the company and often control their financial accounting too. More recently customer and supply chain management can often be part of this ERP solution too, or at the very least managed within the same package of applications.

You also need a system to control the design of your products, for example if you are making a car you need to be able to store all the information, whether technical drawings or documentation to do with the parts, it all needs to be joined together. Some of the leading solutions for this are PTC’s Windchill or UGS TeamCenter. These allow the attachment of local documentation such as Word Documents or Excel sheets to go with the core drawings and are known as PLM (Product Lifecycle Management) products.

Next in a manufacturing or assembly organisation you may need a system to control how you execute the manufacture of parts. These execution systems are the vital link between the planning in the ERP solution and the technical information in the CAD solution. There’s a few of these execution systems available but most now rely on delivery via a simple Web Application interface and many are specific to an industry due to the level of complexity that each has at a raw level.

That might seem to be all you need, after all you can now plan something, create it and make it. There are two other angles to consider though, firstly the reporting of information from this system to the end users in a suitable format. Some companies might choose to use SAP Business Warehouse (in more recent times this has become SAP Business Intelligence) but others may prefer Crystal Reports or Cognos. It is a sign of the issue we are coming to that despite most ERP and PLM solutions coming with reporting tools, these large companies are able to create a market selling tools that report from the reports.

The final angle and perhaps the neglected one is the control of information that is neither to do with the core products or the execution of the core information stream. Information such as this is often usefully held together on an Intranet or local file servers. Realistically a content management system should be used to hold it together though so that it can be accessed in an appropriate manner with version control and reduced chance of data being overwritten.

If you consider that on top of these core parts you may also need a search engine to index all of the information, a copious number of application servers to distribute the information, and a method of access control then you come up with a total of some half dozen centralised systems that are used to control the company data and cover pretty much all users and in some cases there can be as many as ten.

That’s a lot of systems for people to get to grips with how each of them works. Some (SAP) will have their own desktop front end, while CAD systems require a interface for PLM and also the core CAD application. Manufacturing Execution and CMS usually rely on web interfaces, while some reporting apps borrow Excel for presentation and others use their own front end. What we are getting at is the very crux of why this third stage is so hard to reach… Enterprise Software user interfaces SUCK. A good example of why can be found in this article on why Macs are rare in the Enterprise. Enterprises provide feature lists, they provide performance targets, they provide requirements. They don’t provide the intangible “Must be easy to use”.

In our private lives we would not buy a Ssangyong Rodius without a gun to our heads in most cases because while it is cheap it looks like it was cobbled together with sellotape and the bits of metal that were left over from making cans of tuna. When someone uses a Mac day to day, we don’t think it does anything intrinsically better than a Windows box, but we feel better because things are a little better laid out and a little smoother. Vista brings things a bit closer but it’s still got that level of complexity that the Mac hides, and worse the ways of getting to that complexity are more difficult for the enterprise admins used to Windows 2000 and XP. So the question is why do we tolerate such incredibly poor design in Enterprise applications?

Most of the centralised solutions are based on one of two technologies, Java or .NET and I think it would be fair to say that in most cases, Java has the edge because of its platform agnostic nature. Most companies have Windows, Linux, Solaris and Macs floating about somewhere and so this ability to host on anything is beneficial. Interestingly though, many of the applications are also only certified with Internet Explorer, despite all of its flaws and limited platform availability.

What we need to see from Enterprise applications is user interfaces designed for ease of use and able to be used with minimal local installations. There is no reason why anything in the collaborative working cannot be achieved using a web browser to access the information. This gives the user interface familiarity and gives the developer a nice friendly rendering engine making the design easier for the UI too. Whether the application is Java or .NET based does not matter – it should run in any web browser. Sure most desktops run Internet Explorer, but a growing number will be running Mozilla based browsers too, so consider those users next time you certify a product. I know for sure I’d rather my ten thousand seats of web based execution system stations that only display web pages were thin client linux boxes with Firefox than Thick Client Windows XP boxes with IE. Just think of the licensing savings, the power savings and the maintenance savings that could offer an enterprise.

Ultimately though, SAP, Unigraphics et al, your goal should be to make an application that is as easy to use as a CD Player and as beautiful to look at as an Aston Martin while having the technical features of a Lexus. Stop giving us applications that have the technical features of the Lexus with the looks of a Rodius and the ease of use that is known only to government tax offices.

Christopher Hinds : 10 Feb 2008 02:15 |  Tags: Centralised Systems Enterprises Interface Design |  Comments (0) |  Close comments |  Report a problem