Open Source ERP Guru

Communication – you can never emphasize enough how crucial open communication is to the success of any commercial enterprise. Business information systems are designed to facilitate a constant flow of information through the arteries of your company. Another every important aspect to your enterprise’s communication is business related conversations.

These ‘conversations’ take many forms – verbal conversations, over the phone or in person, but also ‘electronic’ conversations, mainly through Emails. Whenever a business event occurs, a conversation is (or should be) triggered.  Let’s take our ATP events, for example – a user notices that stock levels for product A are about to go below safety stock levels. He will send an email to the person in the organization in charge of inventory replenishment. That person will than create a purchase order or production order, and reply back the conversation trigger.

These conversations are attached to any object in an ERP system – to a customer, a supplier, a delayed sales order or a purchasing order that’s long overdue.

The problem with using emails for conversations in a business environment is twofold – emails lack the immediate business context of the underlying  business event, and are ‘private’ – only those who are on the email loop are aware of the undergoing conversation around the business event.

The demo below will demonstrate a conversation module which is embedded into the relevant business object, in our case – a product. A conversation is initiate once a user identified an issue with inventory management, using the ATP viewer. The conversation module will be part of many of the application (in addition to the ATP viewer ) we will release. The way we implemented conversations, other than being in the immediate context of the business event, have the advantage of being accessible by anyone. This level of transparency is extremely powerful in solving issues quickly while keeping an audit trail for future reference.

Business Conversations – click image to view demo

We would like to remind you to register to your RSS feed – it is a very useful way to communicate with us efficiently.

A couple of days ago I got an email announcing the 1.0 release of a new open source ERP solution, called Tryton. It was a pleasant surprise, as I haven’t heard of any new ERP project in a long time.

The Tryton project is an OpenERP (formerly tinyERP) fork, which means the whole thing is written in Python and runs on a Postgresql database server. One of  OpenERP most notable strengths is it’s ease of extension. OpenERP has long offered an impressive list of add-on modules, usually written by 3rd party software developers, extending the systems’ core functionality with vertical solutions, making the solution more appealing to many. I am not sure if existing OpenERP modules work with Tryton, but the Tryton team should at least make sure it’s as easy to write modules to Tryton as it is to OpenERP.

Tryton supports core ERP functionality – accounting, sales,purchasing and inventory management. Manufacturing and Project Management are not yet supported. You can read their F.A.Q here, and a list of improvements vs. OpenERP here.

Similar to other open source ERP projects, the project offers support, implementation and customization services, as the Tryton software can be freely downloaded from here.

We wish the Tryton team good luck with their project. Their investment into the fork demonstrate the ever increasing demand for open source business solution.

We already domed the interactive ATP (Available To Promise) viewer, which is very useful in identifying and preventing stock level problems of specific products, that can lead to unhappy customers. It can also be used to provide reliable answer to your customers’ stock related inquiries.

ATP can be also used in a more proactive manner. This post will demo how ATP can identify possible future stock availability problems within a specified time period, without requiring any user interactivity.

Batch ATP

Unlike the ATP viewer, which is an interactive application, the ATP Notifier works in batch mode. Using a scheduler, a  Talend job, connected to an Openbravo ERP system, is submitted. The job  examines the ATP vector of a list of products. Based on current stock levels, predicted demand (as explained in here) and supply transactions (either manufacturing or procurement orders), the job will indicate which products from the list might have their stock go below their designated safety stock levels, within a specific time period (a horizon), measured in weeks.

The user does not have to submit the actual job – it is run by an automatic scheduler at any given interval (once a day, once an hour etc.). The output of the job is an RSS feed, that can be read by any RSS reader.

Business RSS

A word about RSS – the RSS protocol was invented for people (like myself) who found themselves wasting too much valuable time browsing through numerous websites, looking for interesting things to read. With RSS, you don’t have to surf all those sites – you just register to their RSS feed, and check your RSS reader occasionally, to see if anything interesting is published.

Business users are similar – there are so many business events happening, it is almost impossible to track all of them. Going through endless screens, looking for possible issues with products or customers can be a huge time sink. And this is where RSS can help business users.

ATP Notifier

In the demo below, we run the ATP Notifier on one product (‘Wine United states’), although we could do the same for as many products as we want. We run the Talend ATP Notifier job through a web service call, passing the number of weeks (horizon) as a parameter.

When we pass 6 or 7 weeks, there is no result – that means that within 7 weeks, stock will remain above safety stock levels for our product. But if we change the horizon to 8 weeks, we get an RSS reply, indicating there might be a problem with that product within that time period.

In production environment, though, you would not have to constantly change your horizon-we do that only for demo purposes. The idea is that for every product (or product category), you will define the horizon once. At any given interval (once a day, twice a day etc.), the batch job will run automatically, check all products, and reply with an RSS containing all the product that might have a problem with stock levels within the given horizon. It is up to the planner to solve the issues indicated by the ATP runner, by either creating new production order or purchasing order.

ATP Notifier Recorded Flash Demo – click image to view demo

Our last post introduced an A.T.P. (Available To Promise) flash gadget under development, running on top of an Openbravo system. This post will demonstrate a new feature of the ATP viewer – predictive ATP.

Predictive ATP  is based on a prediction of future demand for a product, rather than on actual demand.

There are many ways to predict future demand. Actually, there are quite a few applications who’s sole purpose is to predict demand . One of the most simple, yet useful techniques is to use time series. By using time series, you examine all of your past demand transactions (sales orders, internal orders etc), and try to predict future demand for a specific product based on these past transactions.

For our purposes, we want to calculate past demand for a certain period, let’s say a month, or  week. So we need to come up with some kind of ‘average’ for that specific time period.

Some of the techniques used to calculate that average are:

1. Simple Average – you could just calculate (by summing all period quantities and divide that number by the number of periods) the average demand quantity for a given item at a given period, let’s say month, and predict that future sales will behave in a similar fashion. This is the most basic and simple method, but also highly unreliable.
2. Weighted Average- in most scenarios, you want to give higher weight to demand transactions that are more recent. for example, when you calculate your new  monthly average, you  could give a weight of 0.6 to the month that just ended and 0.4 to the last calculated average. That way, the impact of the last month on the average is much higher than previous months.
3. Weighted Exponential Average – a more sophisticated version of weighted average, exponential smoothing is a technique in which each month demand figures are multiplied by a factor that decreases exponentially.

The open source ATP viewer now supports all 3 methods of calculating demand. It also features a new ATP vector, that takes into account only the predicted future demand (instead of actual demand).

The way the predicted ATP works is by first calculating average monthly demand for a specific product, based on historical data, and then using that figure to reduce the amount of stock that will be available in the future for a specific time period. The predictive ATP is calculated weekly, so for any future week, the amount of available to promise stock decrease by the calculated monthly average demand, divided by 4.3 , the number of weeks in a month. Similar to the actual ATP, production or purchasing orders increase the amount of stock available to promise.

I highly recommend that you watch the first ATP viewer demo along with this one to understand the business value of the ATP viewer.

Open source ATP for Openrbavo – Recorded demo (click image below to view demo)

We plan to release the ATP viewer as open source, and also provide content that will make it work with several open source ERP systems. If you are interested in using the ATP viewer, please let us know.

You could also register to our RSS feed to stay up to date with more open source ERP news.

A.T.P (Available to promise) is a vector describing how many units of a specific product are available, at any given time in the future, to cover customer orders. A.T.P. is a powerful tool for both the logistic team, in charge of making sure that enough stock is available to satisfy future customer demand, as well as anyone fronting a customer, and has to provide a reliable customer inquiry regarding possible supply dates.

The A.T.P vector takes into account the amount of currently available stock, future supply (from manufacturing or procurement) and future demand (sales order, internal orders etc.). The A.T.P. quantity decreases due to customer orders (and possibly other transactions), and increases as new stock is available, through purchasing, manufacturing or customer returns.

I planned to provide a flash-based A.T.P. ‘viewer’ for open source ERP systems for some time now, and surprisingly enough, I’ve found this feature request on Openbravo’s issue tracker. So I decided to implement a version of A.T.P. that would run as a stand-alone flash application ( which can be easily embedded into your company’s portal).

But I wanted to develop something that would be generic enough so it can be used as an A.T.P. viewer for any open source ERP system (or any ERP system for that matter). I decided to use Talend as middleware. Talend is a powerful data processing tool, and provides one important feature – you can create ‘data services’ that read data from your ERP system, and expose it through a service call to any consuming client.

The client was using flash technology. The front-end was developed using Flex, and it is completely independent of the back-end system. It calls a couple of services, created by Talend, that provide the data used by the A.T.P. viewer. There is still further development required to make the A.T.P. viewer robust, but it is already useful in several scenarios.

I plan to release the whole thing as open source and would love to get help from anyone with relevant knowledge – more on that in future posts.

In the meantime, you can take a look at the A.T.P. viewer in the following recorded demo.

Impaortant! - the data (customer orders, production orders etc.) used in the recorded demo is sample data provided by Openbravo. The dates of the transactions are from 2006 and 2007. A.T.P. always looks forward, into the future. I had to use this data because I do not have access to a live system. So only for purpose of this demo, we assume the date now is somewhere during the year 2005, so all transactions occurring in 2006/7/8 are future transactions.

Open Source ATP Viewer Demo – click image below to view demo