4. ERP

Phoenix embarked upon the path of ERP in 2019. While we could not proceed at the pace as much as we desired, we are making progress in the right direction. We have been conducting series of training programs to all the stakeholders.

In this document we would like to touch upon few fundamental aspects behind “Strategic ERP”, off the shelf yet customised ERP tool adopted by Phoenix for implementation of ERP.

The ERP platform used by Phoenix revolves around Project Engineering Module. The intelligence of the ERP revolves around integration of two core data sets and this becomes the basis for further functioning of ERP. These are

(a) Schedule and

(b) Work break down Structure or WBS (i.e.priced BOQ)

The schedules are normally planned and tracked based on sequence of activities from start of the project till completion. The WBS are group of similar activities grouped together for unit pricing to arrive at overall budget.

For example, casting of podium slab is one of the schedule activities and this work involves say rebar, shuttering and M30 concrete. Unless all these three activities to the desired quantum is not completed, the podium slab activity is not completed. In a typical schedule what one could see is a simple one line “Casting of podium slab” starting on x date and ending on y date but would not have the list of activities involved with in that as described above.

On the other hand, if we look at WBS, it would have various activities for the project as a whole, volume of work to be executed and unit rate agreed with the contractor. So, Rebar, Shuttering and M30 concrete would appear as the line item but one cannot see where all these items are intended to be used and especially quantities required for podium slab.

If the schedule is tracked by sequence of construction activities and WBS are tracked by type of billable activities, no way, one can at a point find out the progress of the work based on the billing or value of the work completed, based on schedule.

So, it is necessary that these two viz. schedule and WBS are linked at the fulcrum of the ERP. To achieve this, we break down the WBS line items into identifiable project locations which are similar to the line items appearing in the schedule. So, in our example, the M30 concrete quantities in normal WBS would be one single item but in reality, it would be used in say 20 different physical locations. So, we break down this (M30 concrete) WBS line item into 20 sub line items and one of them would be podium slab. Such exercise is carried out for all the WBS line items.

In the next step, we assign the WBS (BOQ)code to each of the line items of the schedule. Using the codes, we cross link the schedule with relevant codes of WBS line items applicable for each of the schedule line item and similarly for each of the WBS line item we cross link the same with schedule line item applicable for each WBS line item. The activity line items of the schedule are assigned the relevant BOQ codes and hence the BOQ quantity gets linked to that particular activity line item. So, in our example above, the podium slab as the schedule line item would have the codes of Rebar, Shuttering and M30 concrete from WBS and % of quantum applicable for this task. On the other hand, if we look at say Rebar in WBS, it would have podium slab as one of the sub items with quantity attributable for that activity.

Finally, when we track the daily progress report which are based on schedule line items, the ERP will capture the corresponding value from the WBS based on above linkages and provide us the value of work completed and also the certification of works.

This is a very unique approach however a sound and robust way of tracking the progress. As said, since the business is about construction and delivery of commercial office space and the goals of the construction department is delivery of the building as per the schedule and in the budget, the above philosophy of the ERP matches the way Phoenix is organised in achieving the business goals.

The next aspect of the ERP is data inputs. Unlike other ERP, Strategic ERP uses certain forms to feed the data into the system. There are in all 32 forms relevant for us in the overall ERP and these are divided into following modules.

List of ERP Modules and forms used

For uniformity and better understanding, we shall be calling all the project activities as “Tasks” and the process shall be defining steps or “activities” to complete the tasks. For anyone to operate the ERP, they need to understand which form is used for feeding the relevant data and how to fill up the forms. While ERP is used for certain relevant steps or activities within the overall process, there are some activities within the process that are done offline or outside the ERP. The endeavour is to convert all the activities within a process into ERP but the same will be achieved over multiple stages. At the moment, the endeavour is to go online with what is available off the shelf with minimum customisation.

In the subsequent sections, we have detailed out the process involved in various tasks to be done by the key stakeholders and involvement of ERP with in that.

For anyone to function efficiently, they need to

(a) Understand the process of each task in functioning of the department

(b) Steps/ Activities attributable to ERP within that

(c) How to use the ERP forms to achieve those steps.

The final important aspect about ERP is the scope of functioning. The challenge is how do we map the people and process within ERP so that there is absolute clarity in operations and no steps are missed out or there is no duplication of works. We also need to take in consideration the delegation of authorities.

We have adopted a concept called CVA which is a 3-step process. Every task should be done in 3 steps viz,

1. Create,
2. Validate and
3. Authorise

There shall be one creator, one validator and one authoriser. In certain circumstances where there are inter departmental involvement in the same task, multiple validations and authorisations are permitted for the same step. To bring flexibility, creation has been permitted by multiple users but only one at a time.

To achieve the above:

Step 1, we mapped all the forms within ERP and identified who shall be the creator, validator and authorises for each of the forms, by functional designation within the departments.

Step 2, we mapped all the people and mapped them against the functional designation, such that we can create ERP process authorisation for CVA for each of the form within ERP, by using the unique email id of a person.

Based on the above system, each person within the organisation will be acting as a creator for some of the forms and/or validator for some of the forms and/or authoriser for some of the forms. Seldom the same person will be the creator, validator or authoriser for the same form. Email has been sent to each ERP user detailing their involvement as the creator, validator or authoriser against the corresponding forms.

An overall CVA authorisation chart for step 1 & step 2 as detailed above, is given in Appendix 3.

In addition to the CVA, there is an option to only view. This has been assigned to all the department heads and senior management as they will not be acting on any form but will have access to view the progress and output.

Back to Top