Project Mission:

To demystify, decentralize, and declassify the entire concept of Enterprise-Level CRM (Customer Relations Management), ERP (Enterprise Resource Planning), SFA (Sales Force Automation), MA (Marketing Automation), and Accounting software.

Why?

Business software in use everywhere is really, in the end, very simple. Somehow, however, it has been obfuscated by the huge companies that create sell it. Very strict boundaries are put in place for developers to customize the product for their companies, and the products are very expensive to license and retain support services.

Using good business development principles, and enough effort, it should be only an investment of time to implement a product that will meet the needs of most business software users.

We will try to create a software product that can meet the needs of a wide range of businesses. For now, and until otherwise stated in the software use and licensing accompanying the implemented products, we will be seeking non-profits to implement the software, hopefully at little to no cost to them.

The Basics:

This project will define an open-source standard for the implementation of a CRM system. No implementation of the actual system will be advocated over another. As long as the implementation adheres to the project-defined standards, any implementation is as perfectly valid as any other.

The big picture implementation rules will be as follows:

  1. The back-end storage and business logic layer will be implemented as a REST API. No specific language, just an implementation of a clearly defined REST API.
  2. Unit tests will be defined for the API as if it were a class library, and anyone implementing the unit tests should be able to test any implementation of the API and get the same test results.
  3. Again, storage, language of implementation, and environment all are irrelevant. You could develop the API on a LAMP system, MS SQL and C#, JSP and ORACLE, CGI and flat text files, it does not matter. When the API method is called, it should behave according to the project specification, nothing more.
  4. The front end will be defined as descriptions of suggested appropriate pages only. Design of these pages will be left to the implementing party.
  5. The major focus of the end implementation of the UI will be a mobile-first design.

This project does not have a physical product to produce as an end result. The goal will be to provide a specification for implementation and testing rather than an actual product.

I will personally be developing implementations of the API, Unit Tests, and a basic UI in .Net and sharing them in a public project on GitHub. This will help me in fine tuning the standard.

https://github.com/michaelmayle/OEProject

Anyone is invited to join this project and begin their own implementation in any language (I will create a couple of folders to get us started.)

The Target Template:

For the purposes of having a vision for the product, our initial target will be an imaginary thrift store. The thrift store receives goods from donors and vendors, logs them into inventory, places them in a location, moves to a sales location, sells the product, which then creates sales orders, removes that product from inventory, and updates company ledgers with the money made. This company also does some amount of marketing to perspective donors and buyers.

My .Net implementation of the product will include an inventory control product that the thrift store will use in the warehouse, a cash register product used at the front, and enterprise terminal product used to see the big picture.

Advertisements