What is an ERP Platform

    In this article I will talk about the functional classes of ERP-CRM systems, I will try to describe what exactly is an ERP-Platform system, which one occupies a niche and how to properly organize the system structure.

    image

    In the article I will talk only about cloud systems. Where the user has logged in, registered, and uses. Boxed systems are a separate issue.
    Cloud systems are popular, affordable. It’s easy to get to know them, monthly payments are small.
    For some companies, the cloud is not acceptable. They want to work on their equipment, in their closed network. So calmer. But get acquainted with the system before buying, again in the cloud. You can always make a box out of cloud, but not always out of the box cloud.

    There are many different cloud ERP-CRM systems. I would divide everything into 4 types:
    1) Static
    2) Static +
    3) Semi-dynamic
    4) Dynamic



    1) Static

    This means that the system: how it is done - it is made. The interface is the same for all clients. The developer periodically finishes something in it. Changes in the interface apply to all clients, as common engine. There can be no individualization of the client’s business processes here.

    The option is essentially simple and not intricate. Such a system can be developed quickly.
    But there are practically no more of them, because by screwing the API such a system becomes "Static +".

    2) Static +.

    This is a development of the Static System. It differs in that the developers screwed the API. Those. the user can create (or buy a ready-made) some external application. This application can communicate with the main system, receive or transmit data to it.
    But this partially solves the problem of individualization of business processes. In fact, the logic of the system itself does not change here and the user will still have to adapt to the system. The system will not even make it trivial to make a report sharing data from the system and several applications (data in different places), if of course it allows you to configure reports at all ...

    Such systems are popular - because they are quite simple to create, and if you screw good marketing here, hire good designers, then everything will work out. They can also gather around themselves developers of external applications, integrators, etc. Those. they give bread to even more heaps of people, thereby strengthening their market position even more.

    Static systems are good in some narrowly specialized areas. For another profile, you will have to build a different system. If you want to serve any areas, then a static system is a dead end. Static cloud systems "ERP" can not be, because this requires a deep individualization of customers' business processes, and this can only be achieved by the following class: “Dynamic systems”.

    3.4) Dynamic (Semi-dynamic)

    Dynamic systems - they can adapt to the user.
    They have an interpreter core that can display the interface to the user according to the internal configuration settings. When the user opens the page, the system reads the configuration of this page and builds the elements in the right places.
    The user can independently edit this configuration. Such systems give users unmatched flexibility, adapt to any business process, and allow you to just build an "ERP" system. You can create a configuration that will cover the life of the enterprise.
    As a rule, such systems have an integrated programming system on board. Programming system - the apogee of flexibility of settings. If you develop the program settings all the time, you will end up with a built-in programming system.

    Building a good dynamic system is a big and difficult job. Just with a snap, as a static system can not be done. It is a lot of work and big investments, but it is a higher class system.

    The dynamics of such systems can be different.
    I highlight several points here:
    1) Interface configuration
    2) Database structure configuration
    3) Data processing configuration

    If not all points are implemented in the system, then I attribute it to the class “Semi-dynamical”. I know systems that allow you to create tables and add fields to the database, but do not allow you to configure the interface.

    1) Interface configuration.
    By this we mean that:
    A) you can freely configure the existing interface and create a new interface to the new module.
    B) The interface is “two-dimensional”, and in some cases, “three-dimensional”, if there are layers of options. Those. You can control anywhere on the page .

    There are systems of the Static + class that have realized their problems and are trying to become at least in some form Dynamic by adding new fields to the lists. But this will not solve the problems. Interface management is reduced to a one-dimensional list. And technically this is some kind of universal table with links from what-from-where and blobs to cram any type of field.
    If the system was originally built as a statics, do not beat any crutches to it, do not jump above your head. And when the business is already established - to kill everything and create a new system from scratch - it is very difficult.

    2) Database structure configuration
    You can add new fields to tables, create new tables, make queries in the database, and modify data.

    3) Data processing configuration.
    It can be realized:
    A) A layer between receiving data from the database and displaying them on the screen. For example in php, or some kind of invented language.
    B) Processing data at the database level by means of PL \ SQL and issuing ready-made data to the interface. This is more promising. Here it becomes possible to build triggers, as This is a special case of procedures. In the first version there will be problems with this.
    Also, the entry threshold is lower here, you do not need to teach your language. SQL it is in Africa and SQL, only the interfaces are different.

    This article is about the ERP-Platform system, which has on board all 3 points, and the third point on option B. Data processing is carried out at the database level. There is a complete database configuration cycle from the web interface: tables, procedures, triggers.

    Interface configuration

    In the ERP Platform, you can control each element of the page. At any point, you can organize the output of information, make a control element, display and hide certain areas, depending on the external conditions or user rights. You can create your own new modules, or edit the configuration of existing ones.

    How is such flexibility in individual control of the system achieved?

    Structure of building a web page:

    A web page consists of areas called Bookmarks.
    image
    There can be any number of bookmarks on the web page. The first Bookmark is always in sight. It is located above and in it, as it is, the basic information is displayed.
    Between other bookmarks, the user can switch.

    Here is an example of an application. Above is the main area (Bookmark 1). Below is a list of Bookmarks with their functions that the user can switch to. In the example, Bookmark 3 “Planned” is open.
    image

    Next, the Bookmark is divided into cells. Like in excel. You can combine cells with each other, for example 3 columns and 2 rows in one cell. Any structure for displaying information on the screen is done here.

    Different structures can be displayed in each cell: just text, data from the database, data entry / edit element, table structures, links, etc.

    But just displaying the data in the cell is not enough. Depending on the external conditions, different data or elements may be output to the same cell. Therefore, each cell can have several "screens". It’s like in a smartphone: there is only one physical screen, but there can be many “desktops” and each has its own shortcuts. Also here, there is only one cell, but it can have several screens with different data and elements.

    Also, depending on external conditions, columns or rows of the cell table may be hidden / displayed.

    What are external conditions?
    In the properties of a cell or column / row, a procedure is specified that, when the page loads, will display the cell screen number or condition for the output of the column / row. And already in the procedure, data and conditions are processed, and a decision is made on the conclusion of one or another. In other words, the procedure twitches when the page loads. which gives a decision to output the element or not.

    In some very specific cases, the capabilities of the interface editor may not be enough. In this case, you can embed a php file with this special functionality in the cell.

    mobile version

    The cellular structure is also very convenient for automatic conversion in the mobile version. To display the page "compactly", it is enough to simply arrange all the cells of the page in one column. For example, if a company has developed some kind of its module, it does not need to do something specifically for the mobile version. The module will automatically get into it. But many companies contain entire divisions to develop and maintain a mobile version. And here everything is automatic, without effort.
    Additionally, there is a manual adjustment functionality to increase the “beauty”. It can be noted, for example, which cells do not need to be displayed, or how to shorten the text in the table depending on the format of the mobile output.

    As a result, from this:
    image

    Absolutely automatically it turns out this:
    image

    Universal access rights

    Also, thanks to the mesh structure, a system of access rights is flexibly implemented.
    The access level is detailed down to each page element. You can give the employee access to the page, but restrict it to certain elements of the page, up to individual cells and editing elements.
    The access level can not be specified initially, it is set by default in the cell properties, but overlap unless otherwise specified in the Employee Rights Roles.
    Access rights are also inherited: page-bookmark-cell, unless otherwise specified in the elements.

    Additionally, menu links are hashed with the identifier and session of the user. For example, it will not work, to forward the link to another user for functionality inaccessible to him, such a link will not work for him. Those. the security level is double, both at the menu level and at the level of direct access to elements.

    Due to the flexibility of the access rights system, you can even let external contractors into your account, just set them access rights so that they can see and work only with what they need.

    Multilanguage features The

    multilanguage features of the system are another bonus to the cellular structure. There are no language restrictions. The user himself can add any language and translate system elements into it.
    Each menu item, bookmarks, cells, form elements, etc. can be translated into any languages.
    Technically, this is done simply, there is a table in which it is indicated:
    1) language number
    2) element type
    3) element number
    4) element text The

    user selects the interface language. The system knows the language number of the current user.
    When the core of the system composes the page, it knows the element type, element number, number of the currently selected language and displays the desired text.
    In the interface editor, the number of input fields is displayed in accordance with the number of languages ​​and the necessary information is entered.

    To simplify the development, the Yandex translator API is used, i.e. technically, translation into system languages ​​can be done with one click.
    For example, a new language was needed in the system - nothing is simpler. It registers and runs a script that will select all the fields from the translation table, each will run through the Yandex translator and create a field for the desired language for each element. And vaul, in 10 seconds the system is translated into a new language. The translation is of course technical, but it’s better than nothing, it’s easier for a specialist to fix it than to translate it from scratch.

    An example of automatic translation of cell text
    image

    There are some problems with Hebrew and Arabic, as there is mirroring, but we are working on it. Everything will be automatically.

    These, and many other features, are provided by the correct organization of the interface editor of the Dynamic System.

    The relationship of the interface and the database

    The interface must somehow communicate with the database. Together with the link, the input parameters, for example the Task number, are transferred to the page. By the input parameter, the page displays the necessary information from the database into the cells. The same woman is able to modify the data in the database from the forms filled in by the user.
    For this, there are structures called Data Sources. These are links that describe which procedure to pull from the database, into which fields of the procedure to enter which input parameters, which output parameters the page will receive from the procedure and where to direct them.
    Data sources are Global and Local. Global are executed when the page loads. Local events are executed, for example, when a button is pressed. To record the information entered by the user, a button is indicated, when triggered, the source is executed. In its input parameters, the corresponding fields are indicated, where the information will come from.

    Technically, Data Sources is a structure that allows a page to load on the fly when loading and execute the corresponding query in the database. And then properly dispose of the information received.

    Database configuration

    In the ERP-platform, the user is given full control of his database. The user manages tables, procedures, and triggers. All from the web interface of your account.

    Creating tables and fields is basically standard.
    The only difference from regular databases is the Image data type. The data type for storing images.
    Accordingly, the procedures can also work with him. Data sources of web pages are also able to work with images, as well as cells are able to display them, form elements - to load them.

    Procedures support full PL \ SQL. You can make queries, loops, conditions, string operations, data modification operations, etc. Many built-in system functions.
    There are also unusual structures. For example, you can embed API structures directly in a procedure / trigger. Those. directly from the trigger to the database (by event), transmit information somewhere outside. The user configures the API structure, and configures the addresses where to send.
    Triggers are created on events of data recording, modification, deletion and any combination thereof.
    You can embed procedures in procedures of any nesting.
    There is a task scheduler where you can put procedures in a scheduled start on schedule.

    Editable systems have one feature. To give users everything to edit, a configuration must be developed in this editing system. And since developers themselves, using this configurator, configure the system, they try to automate their work. Therefore, the system has good CRUD tools.

    For example, in the declaration of variables, you can automatically create them based on the data of the selected table, immediately with the name and the required data type.
    You can automatically fill them into into select with a matching name. It is also possible in inset and update to automatically set the correspondence of fields and variables.

    You can create a set of standard procedures for each table. For example, you created a new table. You can create procedures with one click: add data, delete, change, list output, output by identifier. All data types will already be registered in them, the corresponding operations are created. It is very comfortable. If the created by default is not enough - everything can be modified without problems, it’s easier than creating everything from scratch.

    It is clear that a table is not created just like that, usually it is created for some module, and an interface is created for the module. The interface configurator also has all sorts of automation systems. For example, you can create a set of input-edit form elements based on the fields in a table. The system itself will create them, give them names, restrict input by data types, register pattren corresponding to the data type, make automatic technical translation of elements into other languages ​​through a Yandex translator, etc. operations. It remains only to correct something, if necessary, arrange them in the necessary cells of the page.

    In the list fields, indicating the number of the universal directory, automatically create a data source for it and forward its output to the list.

    With the output of table structures, you can also do various group operations on columns.

    Naturally, you can copy cell structures, page templates, form elements, etc. You can even make snapshots of procedures and roll back if something is wrong.

    Thanks to the CRUD approach, development is fast.

    Procedures work fast thanks to compilation. Modern databases are quite a perfect tool, and there is no point in neglecting them. The procedure that the user wrote through the web interface is compiled.
    The system works, knowing the structure of the procedure, and fulfilling the necessary requests to the already compiled, fast-working element.

    Report Configurator

    A powerful report configurator is built into the ERP Platform. A good article was recently published about him ..

    Basic configuration

    Of course, if you provide the user with a bare core of the system, then if it is cool at least a thousand times, it just won’t get it what it is and what it is eaten with.
    The bottom line is that there should already be something on board. Moreover, it is desirable that this something be good, beautifully and conveniently made, and fit most companies without any modifications. A new user, coming into the system, looks at the prettiness and functionality of the appearance, and does not think about the steepness of the internal capabilities.
    It is also advisable to make a “training mode”, where new users will receive a description of the elements, with an explanation of where and where. This approach helps a lot.

    In the ERP Platform, this is called the “Basic Configuration”. If it does not fit somewhere, it can easily be changed to meet the needs of the client.
    The configuration can be developed arbitrarily deeply, to do any complex interfaces and data processing.

    The basic configuration is configured for a complete customer service cycle. CRM - for work on attracting new customers, task projects for work on providing services to customers, applications for registration and solving customer problems.

    Currently, the basic configuration includes:
    - Tasks and SCRUM boards for them.
    - Projects
    - Applications (Xelp Desk system)
    - CRM (leads, offers, deals)
    - Counterparty management system
    - Charts, objects
    - Account reconciliation system

    All these modules are built directly from the web interface of the system. Therefore, they can be easily edited by the user.
    Also, the basic configuration is constantly evolving and being finalized. New necessary modules appear.
    In the general Basic configuration, it is planned to develop niche modules for various types of business. They will hang in "hidden" mode, and if necessary, the user will just need to "turn them on".

    In conclusion, I want to say that it’s very nice when a user’s request changes something, you can answer “ Yes, no problem! ” And immediately solve the user problem, than answer “ For such an individual improvement, you need to purchase a boxed version and then pay us for revision ... money and through ... everything will be ready . "

    A dynamic system makes it possible to organize excellent service.
    - For customers, this is an opportunity to independently change the configuration of their system. The system is not a black box, because having studied the documentation and having understood the Configuration editor, you can make changes yourself. We do not close the editor. It is available to the System Administrator (who created the account) and to employees to whom he will assign such rights.
    - For the owner of the service- conveniently and efficiently serve customers. At the customer’s call, it is possible to make changes to him as soon as possible, and individually, and not change the interface of all clients as in Static systems. The client does not have to study the Configuration Editor, you can just call the support service and they will do everything. And certain volumes of work can be included in the monthly fee.

    Also popular now: