The following demo is purely invented.  Any resemblance it may bear etc.  Anyway, in this example we see how to build a more sophisticated model, to represent our day-to-day processes.  It is very roughly based on a business process model for the installation of telecoms services.  Imagine you are the Manager of that company / service.

Things start with the enquiries received from Potential Customers concerning the installation of telecoms services – work you, as the Manager, know as "Projects".

Each Project involves a number of people, from your business, your contractor and your customer. Throughout the project there are a number of Work Items that have to be handled by the relevant people. At any point in time there will be several dozen projects on the go, some for Domestic, some for Commercial Office and some for Commercial Industrial Customers.

To develop the model – which we know is going to be complicated – we must start with a simple situation. This is the fundamental problem you will face. Sometimes people, who are dealing with a process on a day-to-day basis, struggle to see it in a simpler light. But it will be there!

So, fundamentally in this case, we have;

So we have a Site, that can have “children” of Projects, that can have “children” of WorkItems.

I’ve drawn it a little twisted because the Visio tool I use for these drawings lets me sort it all out later – and I know I am going to have to add a few more items anyway!

Let’s think about how People (Contacts) are involved with this model. Firstly the Site has an “Owner”. So we add in a Contact object and associate it to the Site object as “Site Owner”;

In fact the Site also has an “Applicant”, a “Site Contact” and a “CDM Coordinator”. So we can add these associations onto the model at the same time;

We don’t need to draw them in separately, as they are simply different associations between the same Object types.

Now let’s look at the Project object, mostly something your staff deal with.

Your staff are a little different from a standard Contact type because you have to manage how much their work costs you. So you know you need to add in things like “Staff Rate” and “Employee Number”, though all the other features of the standard Contact object are also relevant (name, email, job description etc.).

So what we do here is create a new object – called "Staff" – on which we put the Staff Rate etc. Then, to get the properties of the standard Contact object, we will “Inherit” it.  "Inheriting" other object types is a great way to use CORE object types, like Contacts and yet modify them specifically for your purpose.  To do this is quick and easy and opens up other features in XPOR that are all explained in a separate Help Resource.

So firstly, let's add the Admin contact;

 In fact your Staff can have a number of Roles within each Project, sometimes an individual has more than one role. Now let's extend the model to the Task:

Now we look at the Work Item.

Your Staff “own” their specific Work Items, just as if the work item were sitting in their In Box on their desk.  Normally you would measure the performance of the member of Staff by checking they process their work in good time and accurately.  Each member of Staff will have several dozen work items on the go at any one time.

The first complexity can now be looked at.

In this case, you know that "Domestic" projects have some different requirements compared to the "Commercial Office" and "Commercial Industrial" projects you work on.  For example various insurances and access rights. Whereas ALL Projects have some common properties, such as "Reference", and "Start Date", Domestic projects have “Residences” and Industrial projects have “Insurances” and Office projects have “Opening hours”.

We could simply put all of these properties on the Project object, which may (will!!!) cause confusion for Users choosing the wrong properties for the right Project type. So we will avoid this by creating three Object types – Domestic Project, Commercial Office Project and Commercial Ind Project – and then inheriting the master "Project" object (another case where we can save a lot of time / complexity by using object inheritance);

Next we can add in the Properties for these Object types.

“Properties” are the standard ways we describe object types – e.g. Name, Reference, eye colour, birthday, post code etc. In our example, as Manager, you will already know the properties of your "things" – often they are already on your standard forms, spreadsheets, database etc.

We’ll start with the Work Item;

In fact some of these properties have Options. For example, the Status of a Work Item.

Work Items are either “Open”, “Frozen” or “Closed” - and, when the Work Item is first added, “Not Set”. We can simply add these options into the model by connecting the Work Item Status to a set of options;

We can complete all of the options for the WorkItem in this way;

So, within a couple of hours (and a few years of working in your business!) you have developed a model that is effectively a template for your organisations’ activities (in this respect).

The following drawing describes the remainder of this business model for this example application.

Next Step 

This is the drawing we take to the Xpor Object Modeller tool, to build as the template for your online service.  From this we can build Forms and web pages to enable your Users to add / edit / manage the objects as they pass through your organisation, from initial enquiry through to sign off.  And, given that each item is connected to each individual, the model will connect tasks to the selected users, manage the deadlines and report on progress.  All through a standard web browser interface.

You will be able to do this, meaning you will be in full control of your business processes AND (at least as importantly!) be in full control of your on-going business development.