Enterprise portals vs CMSes

Note: Initially I was going to call this post "Project Managing Enterprise Portals" but somewhere along the line the post morphed into its current form. I expect this is a topic that I will want to revisit again soon...

In my rather limited experience, I'm finding that SharePoint is often compared against products such as DotNetNuke. I've done it myself. However, the more I'm working with SharePoint, I'm realising that this is a wrong comparison.

Products like DotNetNuke are Content Management Systems (CMSes). They excel at producing web sites that have a distributed content management infrastructure built-in. ie. an administrator can configure certain areas so that business users can readily add content - typically by using a built in text editor (of varying quality) or uploading documents and pictures to a list or library. The content is also typically provided by one person for consumption by many.

While SharePoint certainly does have CMS features, it's wrong to say that it's a CMS. SharePoint and its peers (of which there are only a handful and include SAP and Oracle) fall into a category of its own that could be called enterprise portals. At least this is what SAP calls its portal module (EP - for Enterprise Portal).

Enterprise portals include features to integrate data from a variety of data sources, will have some form of document management service, and will probably have other features as well, including some CMS functionality. Their nature is far more collaborative (many people contributing to the same content) than CMSes are.

Enterprise portals are enterprise systems, on par with applications such as ERP (Enterprise Resource Planning), CRM (Customer Relationship Management) and SCM (Supply Chain Management). It is wrong to compare them to CMSes (as both Bill Simser and Shaun Walker - admittedly in response to Simser - have done).

Enterprise portals are important to a business as they affect the usability of these core systems (eg. ERP, CRM). They allow internal or external users to interact with the core systems without them having to have direct access to it. By not requiring this direct access, security of the core system is maintained. For external users, this means that they can interact with the business without needing to have a specialised client installed on a local computer. They are able to use a web browser and rely on HTTP and SSL to carry and encrypt their data. Additionally, for the business, user support is more contained as custom software does not need to be installed (and supported) on external machines.

The nature of the data usage should also be different in an EP than in a CMS. As stated earlier, in a CMS, the content is created by one person for consumption by many. In an EP, data usage is often also collaborative - ie content is produced collaboratively by many people. The lines between the two categories of product certainly blur: CMSes can do some EP tasks and vice versa but I think there is a difference to be made. Consequently, I also think that the project management infrastructure surrounding them need to be different.

However, I think also that enterprise portals tend not to have the kind of project management infrastructure surrounding them as other ES implementations have, possibly for a couple of reasons:

• They're perceived as just being web sites so can't be that hard to build.
• That they are edge systems, rather than being the core systems that provide the business rules and store the data.

For the reasons above, I cannot say that this is a wise decision. Portal design may often follow a similar process to website design but I'm not convinced that this is sufficiently heavyweight for this class of application. However, project management methodology for an EP is a topic for another post.

Thoughts on implementing Enterprise Systems

First up a disclaimer: my only experience with ERP is SAP and it presently amounts to about 6 weeks. So please SAP, don't sue me for defamation.

For me the jury's out on the value of ERP.

One of the major issues with SAP (and similar) is that can force a business process to change to match the software's built-in (ahem!) "best practices." Best practice is a marketing term that helps to sell things. A more accurate term would be "sound practice."

While there are often many things in common between businesses (especially within the same industry), there are going to be differences. Perhaps these can be because of a business's culture. Culture isn't just an overlay; rather it's at the core of a business and it affects the way a company goes about its business.

In the case of ERP systems like SAP, they are flexible to an extent in how their business processes can be configured but ultimately, the business will have to flex too.

Before starting my masters, I thought that if IT gets in the way of the business process, then the IT is wrong. I think I need to revise it, adding that the business process must contribute value to the business or the business process is wrong.

So let's revise this: If IT gets in the way of a sound business practice that contributes value to the business, then the IT is wrong. It will be interesting to see how this view changes over time. As the semester is progressing, I'm finding that this is the key problem that I keep returning to.

So what would be my advice to someone looking to implement ERP? It would be that implementing ERP won't magically turn the Titanic into the QE2. If your business is heading full speed towards an iceberg, ERP won't save you. It will however, give you a real-time picture of your ship being smashed to a pulp by that little old iceberg and will probably give the duly appointed administrator a decent head-start on salvaging the wreck. I would add that the scope of an ERP implementation is so big it's scary and that you need to evaluate carefully whether there is value in abandoning sound business practices for the practices that an ERP system will impose. The extent of the process changes will have a bearing, possibly a large bearing on the short term hit your business will take in the wake of go-live.