The ERP as a Social Network

"ERP systems are all about some people putting information into a database and other people trusting this information." This is how a member of the "erp-select" mailing list recently defined ERP (Enterprise Resource Planning) systems. In this article we want to explore the inherently collaborative aspects of ERP systems and how to enhance them by using Web 2.0 techniques.

The ERP as a Web 2.0 Platform

According to this definition, an ERP is a place where people meet, collaborate and share information. Obviously, the type of information shared is different from MySpace, Facebook, LinkedIn, and all the other Web 2.0 social platforms. But there are still some important similarities — particularly if the ERP is based on Web technology.

So the questions for us (the developers of the ]project-open[ project-ERP system) is how we can leverage these new ideas in order to improve our customers' business processes.

The Essence of Web 2.0

So what are the lessons we can actually learn from Web 2.0?

Here are my personal favorites:

• User-generated content:
  Provide the users with incentives and they will produce the content themselves. This apparently works better then centrally controlled content generation.

• Using Wiki to reduce "write permissions":
  The main idea behind a Wiki is that basically everyone can create, modify, and extend existing content. Instead of creating permission hurdles to protect content, a Wiki focuses on social self-correction. In economic terms: The cost of not creating content is higher then the cost of eventual removal of contents. Even if certain users' content revisions cause heavy damage, a superuser can usually recover past versions of content, keeping the benefits higher than the costs.
  

• Tagging and folksonomies as lightweight semantic markup:
  The omnipresent tag clouds have managed to replace semantically precise domain models in many applications. Tagging is imprecise, and often nobody can exactly say what a tag means — but it works! No more questions asked.
  

• Interactive (AJAX) GUIs:
  The user-friendly GUI of Web 2.0 applications is an important condition to encourage users to contribute.
  

However, there is one important difference: Web 2.0 applications tend to host a homogeneous group of users, while ERP systems have to deal with widely varying user privileges. For this reason we have to add an important point:

• Powerful but easy-to-understand permissions:
  ERP systems need to provide graded access privileges to collaboration facilities based on the user's hierarchical position and membership in departments, offices or projects.
  

How to Implement the ERP V2.0

Once an ERP system provides a Web GUI, it isn't that difficult to implement some of the Web 2.0 techniques. The following few components make up the Web 2.0 features of ]project-open[:

e-Rooms:

• Everything is an e-Room:
  Projects, customers, users, and other important objects are implemented each as a kind of e-Room (virtual collaboration space)
  
• Access permissions on e-Rooms:
  The rich information in e-Rooms are protected by permissions
  
• Basic collaboration options per e-Room:
  Each e-Room provides a separate discussion forum, space for file storage, Wiki, etc.

Flexible surveys :

• User-definable surveys allow users to express their opinions about ERP objects such as providers, projects, etc.
  

The techniques presented above can flexibly be used in a variety of ERP modules:

Provider Management

By setting up an e-Room for each provider (with forum, file storage, and a survey to rate the provider) you can:

• Keep track with each provider's performance over time
• Engage in a mutual learning process
• Share information with the provider if appropriate (when necessary, negative information can be used to get better deals or spur provider performance increases)
  

Customer Management

By setting up an e-Room for each provider (with forum, file storage, and a survey to rate the provider) you can implement:

• CRM collaboration, by keeping all quotes and contracts used during the customer acquisition phase
• Customer satisfaction tracking, by using the survey facility to acquire customer satisfaction surveys.
  

HR Processes

• 360° evaluations
• Project "postmortem" reports
• Project progress reports
• Satisfaction survey for customers and project members

Knowledge Management Reloaded

The Web 2.0 techniques may actually revive Knowledge Management, because they resolve one of the most difficult aspects:

• KM does not require a separate application with different logins and permissions sets. Instead, KM is integrated directly into the ERP.
  
• The ERP provides a rich context for knowledge-carrying documents because documents are related to people and projects.
• The creation and use of knowledge resources can be directly tied to bonus payments.
• Tagging and other markup of customers and projects may be used to tag the respective documents.
• Clumsy domain models and ontologies are now replaced by "tag clouds" and folksonomies.
  

Summary

Web 2.0 and the ERP seem to be an excellent fit when an ERP is based on a Web GUI or a platform that allows for similar user interaction. ]project-open[ provides a sample implementation capable of demonstrating most of the techniques explained above.

Fun with Financial Controlling

"Any inconsistency in a large system will keep biting you until you fix it.
So don't start off with inconsistent stuff!"

That's an old developer's truth. However, there is sometimes a fine line between real inconsistencies and a complex reality.

Financial Project Controlling Basics

Today's discussion comes from the area of financial controlling, also called management accounting, analytical finance, or simply controlling. To me, controlling is the interesting part of financial management, with its goal of supporting management decisions; discussions of accounting, by contrast, tend to deal more with compliance issues and the sometimes Kafkaesque tax rules.

In particular, project controlling deals with calculating reasonable profit & loss (P&L) figures for each project in a company. This is very important, because it allows a company's managers to identify unprofitable customers and sometimes to detect budget overruns before these problem projects have had the chance to crash.

]project-open[ vs. Other ERP Applications

Most ERP applications are build on an "accounting" financial base, simply because these systems have been written for companies who are producing, buying and selling physical goods. Tracking the value of physical goods through a value chain is the domain of accounting.

However, ]project-open[ has been built exclusively for service companies. For service companies, accounting is nothing but a hassle twice or four times a year. Instead of looking at accounting measures such as circulating working capital, warehouse stock levels, and the like, service companies worry about things like keeping their knowledge workers in the company, perceived customer service levels, and detecting project cost overruns early. And yet these figures don't even appear in accounting balance sheets or income statements.

Controlling with SAP

Large ERP systems such as SAP, Oracle, and Dynamics-NAV also provide controlling functionality to companies' financial managers, but this controlling is built on top of the accounting base. In SAP, for example, controlling is based on reclassifying invoice items based on a number of business rules in order to come up with contribution margins per product class. This is why controlling is an optional module for SAP and the other ERP systems: The core is always accounting.

Controlling with ]project-open[

In ]project-open[ we have designed our financial system the other way around: Invoices and other financial documents produced in ]po[ are first created in and associated with a project. This way, we achieve two major advantages:

• Less information = Better usability:
  We don't need to ask the user to provide the system with the detailed and difficult to understand accounting information
  
• Real-time project controlling:
  By associating financial information directly with a project, all stakeholders get real-time financial information.
  

Export to Accounting

The missing accounting information — account numbers, tax codes, and such — are added in a second step when exporting the financial documents to a separate accounting system twice or four times a year. This step is usually supervised by an accountant who knows his job, so that none of the business managers have to spend their time crunching numbers.

Reassigning Controlling Documents

Up to this point, everything seems fine. But there is one area that causes trouble in ]project-open[: Financial documents that are related to more than one project.

This issue appears in particular in projects with many large sub-projects, where it's necessary to bill more then one sub-project in a single invoice, or when a provider writes a cumulative bill for services delivered for more than one project.

A simple solution could be to split a financial document in two and assign these parts to their respective projects. But by doing this, we would lose the 1:1 matching between ]po[ invoices (and invoice numbers) and accounting invoices.

The correct solution for this issue is to mark a re-distributed invoice as "redistributed" and to create separate financial document "pieces." However, ]po[ V3.3 and V3.4 don't yet support this relatively complex procedure.

The Need for Human Decisions

Instead, we have decided to require a "human decision" in these cases now. So we currently present accountants with an error message if an invoice relates to more then one project.

Inconsistency or Complex Reality?

To come back to the beginning of this article: Is this need for a "human decision" a fix for an inconsistency in the system, or is it part of a complex reality where only a responsible human has the necessary knowledge to make a decision?

We believe that the second option is correct, and that the ]po[ financial system suits its domain better then any of its competitors.

Please let us know your opinion!

Project vs. Product (1): The Underlying Conflict

One of the most persistent discussions in the ]project-open[ community is "Project" vs. "Product".

What is a Project?

There are many, many definitions of what projects are and what not. For us, the ]project-open[ guys there is an easy definition: "Get stuff done. Be fast! But make the customer happy!"

What is a Product?

A "product" in contrast (our ]project-open[ application) is something completely different. This has even a kind of esoteric dimension: "Do things right. Right from the beginning!". It is obviously very questionable waht "right" means. But it is clear that the "product" should not include quick & dirty hacks and similar constructs.

Instead, the "product" is something that we will push - earlier or later - to our ~2.500 customers around the world by means of a product update. So "product" is about responsibility, security, extensibility and many more.

Another Definition of "Product"

In a nice conversation with Dennis Riedel of Opus5 we came up with a nice alternative definition of "product": It's the least common code denominator of > 3 customers. Dennis' background is custom web site development for a number of high-profile customers. Their (Opus5) problem is that every customer has very special ideas on how their application should look like. So coding at Opus5 includes a code reuse strategy of "copy-paste-modify" then "productify".

Customer Variability

So here is a core characteristics of a "product": A single code base has to serve a number of customers. Specific customization should be reduced to a minimum. Instead, a "product" is supposed to include a number of parameters so that you adapt the product behavior to a range of customers.

But what happens if a customer doesn't fit into this corset?

Difficult question: Some companies would take on high-profile customers and mess up their product; these companies tend to be successfully in the short term. Other companies would reject such a customer and go for "scalability". These companies tend to be more successful on the long term. But there are always exceptions...

Turning down Customers???

So does that really mean turning down customers? Any sales guy may consider this to be heretic thinking. But yes, in order to "keep the product clean" you need to turn down customers who would pollute the "product" (remember? The beautiful piece of code that is the base of your business...) too much.

Conclusion? You will get trouble if you don't listen to your sales guys, but you will also get into trouble if you don't listen to them at all.

Conflict Lines

A "conflict line" in the context of "Project vs. Product" is the separation between:

• the "product guys", the "guardians of the pure code" and
  
• the "project guys", the people who create happy customers

From the text above we can already assume that none of the two can exist without the other one. However, each customer's project will come with a struggle between the two sides.

The Beauty of Conflict Lines

But here comes the beauty of a conflict line: If both projecties and producties take their job serious, they will - with some moderation by senior management - come up with a nice compromise, satisfy the customer and during that process enhance the product.

How?

Stay tuned, subscribe to this channel and ask for more! There will be more coming on conflict lines and project vs. product.

Frank

The "return_url" Web-Pattern

This "pattern" or programming style addresses a frequent issue in Web-applications.

Page Flows

One or more Web pages form a "page flow", i.e. a logical unit of pages that belongs together. The most simple flow is the combination of an "EditPage" (a page showing information about an object in a form) and a "SavePage" (a page saving the modified data to a database). More complex flows include "wizards", workflows etc.

The Anchor Page

Most of these flows start off from a certain page, which we want to call anchor page. The intuitive behavior of the application is return to this initial page once the flow has successfully terminated. However, a flow may be called from more then one anchor page. So the last page of a flow usually contains a quite ugly logic to calculate where to return.

The idea of the "return_url" pattern is to avoid this ugly logic and to replace it by a single parameter provided by the anchor page (or more general: page that initiates the flow).

Passing "return_url" Along

Nearly all pages in OpenACS and ]project-open[ contain this (in-) famous "return_url" in one or more places. There are two main places:

1. In the Link at the Anchor Page
   It is the responsibility of the anchor page to "call" a flow with the URL of the anchor pages as return_url.
   This is a kind of "inversion of control": Instead of the flow, it is the anchor page that tells the flow to return to the page.
   
   
2. In the "Page Headers" of the "flow" pages
   The code "{ return_url "" } is found in the "Page Header" of most ]project-open[ page. The "Page Header" is like the declaration of parameters of a procedure, only that it takes its variables via URL or HTTP POST commands. It is particularly nice that you can specify a default value for the return_url if it shouldn't have been specified explicitly by the user/application
   
   
3. In the forms & links of the flow pages
   Each flow page needs to pass the return_url to the next page. OpenACS/]po[ has several commands such as "export_form_vars" that automate this task, for both forms and links.
   
   
4. At the last flow page
   The last page of a flow executes a "ad_returnredirect $return_url" command as the very last action. This commands will redirect the browser back to the anchor page
   

Code Samples

For code samples please see any ]project-open[ package and search for "return_url". You can download the source code of ]po[ from SourceForge at the download section of http://sourceforge.net/projects/project-open/.

Summary

This "return_url" pattern is definitely no rocket science. However, this simple "inversion of control" frees the flow pages from ugly, obscure and difficult to maintain logic and allows page flows to be reusable for different anchor pages.

Or to put it in another way: Any rooky still coding "page flow controllers" should know that there are more elegant solutions out there...