Sales Order Processing (Part 1 of X) - Business Entities

In the next posts we will use the following process to analyze and determine what aditional information is needed for the "drawing" of the process to turn into the supporting business application.

If need be, we will modify the model, add metadata to it, define new icons, etc. in order to have the necessary information to generate the application.

The idea of the process is:

1. We receive a Purchase Order (PO) from our customer
2. We create a new Sales Order (SO) in our system referencing the PO.
3. Once we enter the SO the commercial information is checked or added (prices, comissions, etc.)
4. Customer financial status is checked (credit limit, overdue invoices, etc.)
5. Inventory is checked
6. When the order passes the three check it is ready to be processed and a picking list order is sent to the corresponding warehouse
7. At anytime we can receive a notification to cancel the open order

We could make this process a lot more complex by going into detail such as the posibility of receiving a PO by fax vs a PO by a web service in XML. We will try to do the basic process (completely manual) first and then try adding thigs as we go along.

In order for this process to work the following business objects or business entites must exist:

1. Sales Order
2. Customer
3. Product
4. Picking List

In my blog entry Business Application Development, I defined certain components that should be present in order to generate Business Applications with just a Business Model. These components were classified in five areas: Model, User Interface, Business Process, Services, and Data.

In order to edit business entities we must have:

1. Model: Business Entity Definitions
2. Model: Business Process
3. Model: Contextual Security
4. User Interface: Generic Business Entity Editor (use of reflection to generate GUI)
5. Business Process: Business Entity Validation Rules
6. Data: Persitence Framework
7. Data: Business Entity Repository
8. Data: Master Data Management process
   

SAAS - Software or Services as a Service?

Before starting the exercise I mentioned we would do on my last post, I would like to put a thought out there...

Many vendors are coming out with their SAAS (Software as a Service) solutions and they are usually some kind of business application with a specific purpose. I think the idea is great but I just don't see a company working with too many of these logging in to different web pages to use different applications. I don't even want to think about the nightmare of making different SAAS Applications share information.

Though mashups would help put different application GUIs together in one place, I believe the correct approach is to have SAAS (Services as a Service). A web application or a desktop application ca use these services but the data flow is managed by the underlying business process.

As an example we could have different Production Orders that are sent to a service called Production Planner that would result in a Production Plan. In our business object repository mentioned in an earlier post, we would have Production Orders and Production Plans. We have the option of generating a production plan manually or sending all our production orders to a service (Production Planner provided by a certain vendor) that using a linear or non linear optimization process would generate the information necessary to create a Production Plan.

This is the approach I will be using in this blog.

Business Process Modeling

So how much information do we have to cram into a graphical representation of a business process in order to generate a complete application? For sure popular modeling methods such as IDEF0, UML and BPMN are not enough... but should they be discarded?

Definitely not! Maybe we can agree on a mixture of them or complement just one or two of them with metadata that would help define gaps presented with the chosen models.

Of course the idea is not to generate 100% of the needed source code, compile it and voilà we have our application. Much of the processing functions are going to be already implemented by skilled IT developers and are going to be delivered by different vendors as services. On the other hand, data entry would be done by defining business objects that are somehow persisted to databases, files, etc. and GUIs to create, read, update and delete can be automatically generated from this information.

The idea of the graphical model is to coordinate all of this into an enterprise application. I believe a complete model has to define:

1. What is being done and in what sequence
2. Who is doing all these activities (manual vs automatic)
3. Information/Data flow between activities
4. Security, business rules and other restrictions on how things are done

Because of the increasing popularity of BPMN, it is a good standard to base the modeling on. Unfortunately BPMN v1.1 only addresses points 1, part of 2, and very little of 3 and 4. We will have to create aditional metadata in order to fill the gap.

In following posts we will go through a Sales Order generation process starting from the customer's Purchase Order, generating the corresponding Sales Order until it's approval and the instructions to satisfy the order are sent to the corresponding warehouse (Picking List).

Let's see what we will come up with.

What's Wrong with Today's Enterprise Apps?

Here are a few things I've com up with:

1. Business processes are forced to adapt to the application
2. The systems are customizable but only through limited prametrizations or a lot of specialized development
3. Many ERPs are very centered on accounting
4. Hard, expensive to integrate solutions from multiple vendors
5. Lots of unused functionality
6. Security settings are very rigid

How would the new way of developing enterprise applications solve these things?

1. The business process defines the application
2. Changing the model, changes the application. Business users would be able to do this in most cases (as long as services exist that support the new process).
3. Accounting transactions is a satellite service. The business process is where the center of attention is located.
4. Different services can be provided by different vendors. The business process modeling language would orchestrate the interactions between them.
5. Only business processes relevant to the company would be defined and the relevant services would be used.
6. Security can be defined in the context of each business process depending on who is running the process and what stage of the process is being executed.

I will update this list as well as I think of more issues. Of course there has to be a trade off for all these benefits but we can discuss those some other time on another post.

Business Application Development

Business people in charge of a particular business process in a company should graphically model it and the supporting business application should be automatically generated.

Of course this is only the tip of the iceberg since a lot of "things" have to happen in order for the above to work. These "things" are what I'd like to discuss in this blog and, with your help, conclude something that helps steer things in that direction.

Business or Enterprise Applications (ERP, CRM, MRP, etc.) operate in very similar ways, especially if you look at them from a technical point of view. You have different data entities that are created, used and/or transformed in different processes following certain rules. In order to retrieve data from these systems some kind of reporting tool is provided. Parametrizations are posible to change certain behavior, there are security settings as well as auditing functionality.

By generalizing these functionalities and trying to define components that would help us build such applications, I came up with the following list (by no means comprehensive):

Model

• Business Process Modeling Language (Workflow & Metadata)
• GUI editor
• Business Entity Class definitions

End User Interface

• Mashup composer (for different platforms/devices, not necessarily web)
• GUI generator

Business Process

• Business Process Engine
• Business Rules Engine

Services

• Business Services
• Auditing Services
• Communications Services
• Task Management Services
• Document Services

Data

• Reporting Engine
• Data Warehouses, Data Marts, etc.
• Business Objects Repository
• Master Data Management

With these components, the way we develop enterprise applications will change forever (I will be editing this list by adding/removing components or finding better names for the components).

Until next time...

An Introduction

OK, I've been hesitating for a while now on starting a blog so here is my first try at it.

Though I've programmed all my life and like to do it as a hobby, my real passion is designing software (especially applied to business problems). Any time I have a conversation with someone about anything, in the back of my mind I will be designing a software that can do this or that.

I am a computer science engineer and industrial engineer from Universidad de Chile's Engineering School. I also studied a Master in Business Engineering at that same university. I am currently taking an MBA (specialized in management of technology) at Georgia Tech.

Since 2002, I have been working for SQM which is a Chilean mining company and have had the opportunity to work at their commercial offices in Chile, Belgium and the United States. I am currently the Regional IT Manager for the AMERICAS taking care of the commercial offices in the United States, Mexico, Peru and Ecuador.

At SQM I have been involved in internal development (VB, C#.NET, VB.NET, ASP.NET), have designed and implemented different data warehouses and BI solutions (Cognos, Business Objects, MS SS Reporting Services and Performance Point), have implemented Dynamics AX in different subsidiaries, and helped redesign some business processes. I have worked in the business side of the company as a business analyst and also in the IT department.

Not being in a technological company, I believe to have a point of view of how technological business applications/solutions can be designed and developed in a more agile way, in a way that both people from the business and IT are involved, in a way that the solutions are flexible enough to change as the business changes.

I am a fan of Business Process Management (BPM) and I believe that the technologies that can help us design, implement, monitor and optimize business processes are the same ones that will help us build the software that supports them.

That is what I want this blog to be about.

OK... that's long enough... thanks for reading!