ERP, what’s next?

I recently found a really provocative and interesting article about the current status and trends for ERP software applications.

Without any doubt, many customers of the “Big ERP” vendors, feel the weight of complex, monolithic systems that have piled – over the years – an impressive amount of investments. Despite this situation, I believe that there are now some factors that will, soon or later, spark a completely new generation of solutions for middle, big, end very big business.

If I look at my professional history, maybe the initial growth of the main ERP solutions (SAP, JD Edwards, PeopleSoft, Oracle, etc.) was based on two, technological, disruptive factors:

– relational databases,

– availability of long-range data connections

The first one allowed to build scalable applications, able to process quickly vast amounts of data (“vast” in the scale of ’70 ’80 of the previous century).

The second one allowed Companies to dismiss the multitude of “local”, strongly customized, applications, and concentrate to a single, standard, application platform accessed remotely from all the plants, sales, offices, local branches, etc.

Today, we have, at hand, some new technologies – first of all unstructured databases (NoSQL) and strong transactional databases (Blockchain), plus cloud, service orientation, Big Data, and all the commercial hype that vendors are eager to promote.

The big – and emerging – ERP producers are reacting adding new, and fancier, user intefaces, additional modules, but, in my opinion, are failing on some key points. They are adding stuff on top of existing applications, leaving the underlying architecture untouched. 

Furthermore, they failed to recognise the growing importance of the “personal information” aspect of document processing.  This lead to attention on the “presentation” features of user intefaces, rather than on the “content” of the interface. there are still strong barriers dividing the enterprise side of the information from the personal side. This require,  to the user,  frequent context switches. 

So I tried to imagine some features for a “New ERP” software architecture.

  1. Each transaction should have an url

If you are reading my post, you can easily share it with someone else, simply passing him the link to the browser page (or using the “share” button embedded in all the mobile apps). Your friend will receive your share via mail, or some other sort of generalized messaging or notification system.

If you are watching at an invoice on your ERP system, you cannot do this. Maybe you can, if your colleague operates on the same software and he is logged on same server.

In my dream ERP, every customer order, GL posting, article master data, purchasing request should be available as a single page (web or mobile doesn’t matter) with a simple link (obviously requesting all the authentication and permission checking stuff).

  1. Single repository

All the documents (EDI, pdf, etc.), mails, chats, comments, records should be available in the same “space”.

They may be physically dispersed in several locations or cloud systems, but their index should be unique, exactly as the index of a search engine is unique, even if indexes millions of different servers.

Please,  note that,  for me,  email should be a totally integrated feature.  This mean that the mail server should be a module of the system,  and should be able to tag each incoming mail with the relevant references,  analyzing the semantic meaning of the message body and attachments.

Microsoft, for example, is pushing and claiming it’s messaging app Outlook integration with it’s NAV ERP solution.

  1. Search

The fastest way to find something should be the search box.

You type “Invoice june 2016 ACME”, and you get the list of all the invoices issued in the month of june to/from ACME. But ALSO the mail that you have exchanged with the salse rep about this invoice, maybe a report where this invoice is listed.

You will be able to browse and refine your search.

The key point is that ANYTHING should be indexed, not only the “keys” recorded on transactions. If there is a customer order with a description containing “provided by ACME Corp.”, it should be in the result list, even if the customer/supplier is not ACME.

Search should go beyond content searching; I think that also menu items, user guides, how-tos, should be searchable in the same way. So, if you have to post a new lease-out contract, simply type “new lease-out contract”: the result list will show you the link to the active page where you can post the contract, as well as a link to the guide, maybe also an alert, telling you that – from the first of july – “lease-out contracts should be posted under a new category”, or something else.

You will be able to save anything in your favourites, be it a document,  a menu item, a mail.

  1. Social

Social ERP doesn’t mean a bad Facebook clone with a different name and your Company directory preloaded.

It means that all the documents/records that you process, your comments on them, your approvals or rejections, will be part of a content stream, categorized under many keys (“Project X”, “Lead Y”, “incoming invoices”, “maintenance requests”) cleverly assigned to each item.

So, if you have a purchasing request that is approved by your boss, you will read this event in your main stream. But if your boss has some issue on it, he will simply annotate the request, you will receive this notification, and will be able to see it in the context of the request, not as a separate mail.

And a mail, coming from a vendor, will become a document, within the stream related to your purchase requisition. Your collegues will be able to comment it, and, if properly configured, each comment will become a response mail to the original author.

5. Workflow and capabilities

Workflow automation is a great tool,  when you follow a course about process modelling,  or you watch at a demo.  Why business executives dislike process models? Because they are a mess. And they are a mess not because your organisation is poorly designed,  or is overwhelmengly complex, but because reality is flexible,  fuzzy, and it has to be so.

A modern ERP should incorporate Workflow management,  but only as a “main” process path,  keeping track of milestone approvals,  allowing a flexible “I will take charge of this” pattern. The system should provide you with a clear view of the process pipeline,  highlight exceptions,  and allow a flexible collaboration on each item.

6. Related content

It means that you should be able to find,  and link,  anything that you find that is related to the content that you are viewing.

People working on items,  tend to manage them mainly as a chronological sequence,  all the other forms of archiving are useful,  but not “natural”. Then,  when they read an item,  the association mental mechanism happens,  and their memory suggest the existence of related content.  This should be naturally implemented in the system,  thus simply enhancing the natural power of the user’s mind. 

Related contents may include documents that have a functional relationship (an order with a goods receipt,  a VAT posting with an invoice) that will be managed by the system, as well as mail, memos, spreadsheets,  drawings,  that can be useful for evaluation, knowledge sharing,  and the else.

  1. Really modular applications

Localization is always an issue. ERP vendors are requested to maintain some functions (eg. VAT, Withholding tax,  property tax), or to develop some functions only for one country. This has a cost, a huge cost, and customers pay this cost, in term of maintenance fees. I live in Italy, where the regulator is often tricky, and new requirements, fiscal reports, blossom every year, and ERP vendors often don’t provide a timely, simple, and fully effective solution. Maybe, the fact that the local functions are developed offshore, by people who haven’t ever a “field” experience of our normative reality, is a factor influencing the final quality.

In my vision, a localized application for VAT will be developed only for Italy (or India, Argentina, USA…) by a local software developer, with strong ties and knowledge of the evolving regulatory landscape. When you post an invoice, you will generate several, related (see point 6), different documents:

– the invoice itself, with metadata describing only the essential information (date, number, vendor, total amount, customer);

– the general ledger document, with only account codes and amounts;

– the VAT document;

– the Withholding tax document, if required;

– the financial (account payable cash flow) document;

– the good-receipt clearing document.

This means that:

– the application footprint is small;

– user interfaces require a careful design (but this is already true for the legacy, monolithic, applications);

– different document are linked only by a “structured” link, made by the document url, and few integrity constraints based on document values

I listed only few elements that I believe will characterize the future generation of ERP systems, and are made possible by the technologies that emerged in the past years. I am convinced that a new software development approach, conceiving the application as something mixed or meshed with common use tools, like mail, document systems, social networks, will provide agility, ease of management, and – at the end – an impact on the bottom line of P&L!

Some of my thoughts are shared by key players in the ERP software industry (look,  for example, this interview with the SAP Fiori guru). But I haven’t seen yet a full conceptual design for a “New ERP”.

Advertisements

2 Comments

  1. Thanks Massimo for your very interesting and inspiring article.
    Looking forward for a federation of connected applications as a service that can cooperate on a common tecnology platform.

    Reply

  2. Massimo, what you want is happening.

    You might be interested in a series of developments toward NRP (Network Resource Planning) for economic networks, not single enterprises. NRP is a total redesign of ERP that has been percolating and developed in several projects, possibly starting with this article http://www.jeffsutherland.org/oopsla2000/mccarthy/mccarthy.htm

    Here’s an explanation of some of the differences, from the wiki in one of the NRP software projects:
    https://github.com/valnet/valuenetwork/wiki/Differences-between-ERP-and-NRP

    Here’s a new project, combining several NRP forks:
    http://rea-project.readthedocs.io/en/latest/intro.html

    The basis of all those projects is the REA (Resource-Event-Agent) model:
    https://msu.edu/~mccarth4/

    Two other related projects are starting soon, one to redesign https://www.odoo.com/ using REA, and another to create a blockchain system based on REA.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s