Universal ERP
Image by Shing Hin Yeung [CC BY-SA 3.0] via Wikimedia Commons
ERP systems drive businesses. There is very few companies left that do not rely on some form of ERP system. Each ERP has its strengths and weaknesses, companies spend a lot of effort choosing the right system. Often that choice comes down to a compromise; they have to choose the system that fulfills the highest percentage of needs or they go with a vendor who is able to customize an ERP to the desired degree. Limited feature-set and customizability are some of the major downsides of traditional ERP systems.
Most ERPs run as two or three-tier applications. There is usually a database and an application or web-server feeding desktop or web clients; the application logic is implemented in the application/web server. A simpler ERP might have clients that connect straight to the database. Some systems implement the application logic partially or fully in the database layer. What they all have in common is that they use some sort of proprietary protocol to store data, often a relational database.
Companies who use ERP systems are often caught by rigid processes, unable to adapt quickly to new business needs. It can take months to implement even minor changes. That can be caused by bureaucratic reasons. But more often than not, a change requires custom development and a new release. A simple feature request for an additional field can take multiple months and cost more than a family car. Sometimes vendors are reluctant to implement features because it does not fit into their general strategy for the product.
In a universal ERP, data and functionality are modelled using Havel and stored in universal repositories. It is driven by the concepts of universal modularity and information-centric computing. It is not a monolithic solution from one vendor but a merger of a multitude of modules from different sources that together form one seamless solution. Business managers can create their own modules or obtain ready-to-use modules through community sharing platforms or buy them from commercial solution providers.
Community shared modules and community support are at the core of the universal ERP universe and are intended to be used by private users, small businesses, NGOs and communities. Modules are shared or sold on a virtual marketplace. For corporations and governments, commercial vendors can provide advanced/specialized modules, consulting, custom development (e.g. specialized interfaces into other systems), professional support, cloud services and SaaS.
The maybe biggest difference to a traditional ERP is that a universal ERP is not bound to a fixed database, not even to a fixed protocol or schema. Most functional module work with any data they understand, the data just needs to be semantically compatible. Where it is coming from (and going to) is not important. Be it from a normal record inside the main repository, from a draft a salesman has scribbled on his NME while on the phone with a client, from a sales order that has been received through a communication interface, an ad-hoc expression generated by a translator interface to a different ERP system. All these records automatically merge with the system’s infoverse and can be validated and if necessary extended in order to ensure data integrity. When working with universal data, information just IS, place and protocol are secondary. Also, Havel offers features that facilitate the integration of semantically incompatible expressions and PODS (a.k.a. plain old data structures). Together with protocol-free communication, this is nothing less than a revolution in business-to-business and customer-to-business communication and collaboration.
A universal ERP is state and context-driven. The state of an entity is determined using Havel’s powerful state and flow grammar, context is provided by the user, the environment and other factors. Functional modules adapt to state and context and present data and functionality accordingly. They can for example choose from different production modes, i.e. information-centred, task-centred or process/production-centred. In the information-centred production mode, the user focus is on data acquisition and manipulation, for example a call center user that is creating and managing sales orders. In the task-centred mode, the user focus is primarily on tasks, for example order processing, invoicing or stock management. In the process/production-centred mode, the user focus is on a specific process, for example a production or logistics process. Different modes give different views on the data and provide different functionalities. Processes are freely configurable (and programmable), business managers can use the full power of Havel in order to create processes that cover every aspect down to the smallest detail.
A universal ERP benefits also from some of Havel’s standard features. Universal extendibility for example allows any data to be freely extended when necessary (and allowed), opening the ERP for non-standard business cases. Dynamic expressiveness allows data to be recorded down to the smallest detail while not losing any of its semantics. Universal encryption allows seamless integration of data encryption into business processes, universal signatures can ensure information trustworthiness and temporal dimensions allow for detailed manipulation tracking and activity logs.
OS-native applications (i.e. normal applications running on desktops and mobile phones) can access Havel data and functionality through different interfaces and can be integrated into the functional modules in Havel.
Some of the main benefits of a universal ERP over a traditional one:
Less initial investment
Less vendor dependence
Allows for multiple vendors/sources
Universal customizability
Universal modularity, no vendor limits
Custom modules created in-house without need for software engineers
Individual business know-how can be more easily integrated
Can be tailored to integrate with existing processes and philosophy instead of the other way around
Digital information becomes more fluent, touchable
Processes can be defined much less rigidly while being more complex
Much faster reaction to new business needs possible
ERP can be less dominant without losing any of its management power
This post is part of a comprehensive introduction into SRDM, graph languages and Havel.
Continue reading: Technology
Comments