CUSTOMER ORDER DECOUPLING POINT ISSUES IN A PROJECT ENVIRONMENT

Nowadays, one of the most dynamically developing knowledge areas is the one of Project Management (PM) – both in the fields of Business and Public Administration. This is truth, partially because of constantly increasing customization of products and services, and the way to successfully cope with fulfilling customer orders, no matter if they are individual, industrial, or government ones. The key is the usage of Project Management tools and methods. On the other hand, the concept of Customer Order Decoupling Point (CODP) is a popular approach to increasing the diversity of end items, while taking advantage of standardization due to increased repetitiveness of operations devoted to producing components and/or subassemblies. It is widely used in Operations Management, but it could also be applied on a “secondary” level during the process of project implementation, and thus an increased customer customization could be achieved. In the present paper, the usage of methods and techniques such as Design Structure Matrix (DSM), Analytical Hierarchy Process (AHP) and others is discussed in a model developing, which helps in defining places throughout the project implementation process the interaction with the customer is to be realized, while avoiding undesirable violations in the project workflow.


INTRODUCTION
Business organizations cannot afford not to offer their product/service the way it is expected by customer.In this respect, new concepts and approaches emerge that provide an increasing customer involvement in added value creating.Among them are: "Mass Customization" (Pine, 1992), "Co-Creation" (Prahalad & Ramaswamy, 2004), "Customer Order Decoupling Point / CODP" (Andreev, 2009;Van Donk, 2001), "Prosumer 7" (Hughes, 2010) etc., thanks to which the competitiveness of business organizations is also being significantly enhanced.These and other concepts lead in a natural way to the usage of Project Management (PM) instruments for planning and fulfilling individual customer orders.This way, the customer easily becomes a partner of the organization, which (s)he cocreates benefits with.
In this environment, a necessity arises for a tool to profitably define the places within the operations frame (processes, workstations, decision making points, etc.), up to which the customer could (and/or should) be "admitted" without causing undesirable violations of the project workflow, while achieving an additional increase in product/project goal customization.
In the present paper, we propose such a model for PM, which helps in defining the places in the project process where the interaction with the customer is to be realized, as well as the ways by which it is done.It is also a further development of some ideas, presented in Panayotova and Andreev (2011).

CODP NATURE FROM A PROJECT MANAGEMENT STANDPOINT
The concept of CODP, which is widely used in Production and Operations Management, offers a combination of Economies of Scale with a greater diversity in the product mix (Economies of Scope) as specified by the customer by the means of his/her order (Andreev, 2009).Many authors use different terminology for that: "Customization Point" (Pine, 1992); "Delay of Product Differentiation" (Gupta & Benjaafar, 2004;Swaminathan & Tayur, 1999); "Point of Postponement" (Feitzinger & Lee, 1997), "Order Penetration Point" (Olhager, 2011), or just "Customer Decoupling Point" etc.
Figure 1.Specifics of customer order decoupling point (Andreev, 2009) In general, the idea of CODP is presented on the Figure 1 (Andreev, 2009).On the top of the figure, a simplified view is used to depict the sequence of operations and supplier-client relationships.It is repre¬sented by the subsequent steps of the whole supply chain -from the suppliers of raw materials downstream to the end clientthe customer.
According to the position of CODP, the customer is "allowed to penetrate" through the operational process using different options to choose at the CODP itself.Thus, (s)he could define one or more particular sub¬assemblies (com¬ponents of the end item) to be used in the final assembly, or the components of any particular subassembly, or a given combination of both, as well as to define certain component parts, and so onupstream to the beginning of the process.
The philosophy of CODP therefore is founded on the opportunity given to the customers to determine the final appearance of their end product/service, by means of their choice among a number of alternatives offered at CODP.
Using the CODP philosophy, one can identify different strategy options (Andreev, 2009;Gupta & Benjaafar, 2004): -Distribution/Shipment to Order; -Packaging/Labeling to Order; -Assembly to Order; -Make to Order; -Purchase to Order; -Design and Produce to Order/Engineer to Order (the case of projects).
Often, in a particular company, a mix of these is used, according to the market niche of the corresponding product or product family, as well as to the characteristics of different product families of the company.
In spite of the fact that in the case of projects, by definition, the overall CODP position is located at the beginning of the process, during the project implementationbecause of the iterative nature of many project activities -often the particularization of and concordance with the customer are required.In such cases, through a "secondary iteration", it is possible to apply the philosophy of CODP on an internal project level, thereby achieving an additional customization of a particular activity, project process, project product and so on.
And since presumably the customer participation is particularly important, one should primarily determine when and under what circumstances customer involvement in the project would pose on a danger of undesirable development and/or rejection of further implementation of the project.Hence, a tool is needed to help with this problem.

A CRITIQUE ON DESIGN STRUCTURE MATRIX AS A PROJECT MANAGEMENT TOOL
Besides mentioned above, there are cases where the use of the most popular tools for PM, such as Critical Path Method (CPM) and Program Evaluation and Review Technique (PERT) is impossible.It happens because, for instance, no iteration cycles in the network models are allowed (Andreev, 2006;Damyanov & Panayotova, 2007).A similar problem occurs almost each time during designing and developing the project object (for example, the product and its components), as well as when composing project teams, and so on.These interdependent relations and/or information flows can be analyzed and "incorporated" into the project network through the usage of Design Structure Matrix / DSM (Steward, 1981).
DSM is a universal tool that can be used to study the interactions, dependencies and information flows among the elements of any system, and in this case -the elements of the project.Although there are many examples of its application in projects aimed at creating and developing new products and product families (Browning & Eppinger, 2002;Eppinger at al., 1994), as well as in formulating and planning project teams work (McCord & Eppinger, 1993), it is still not paid enough attention in the literature to the very interaction with the customer during project implementation and to the consequently arising additional dependencies, re-planning, and other iterative processes/cycles.
The algorithm proposed by Steward (1981) lies in the basis of the developed in the present paper procedure for defining eligible areas of the customer's influence in the project process.It contributes to the "right" rearrangement of project activities/tasks (i.e.processes, project product components, teams, etc.) in order to be consistent with different types of interactions and dependencies among themaccording to the nature of their work, information flows and so on.
The main advantages of using DSM are: (1) It provides an easy way of presenting links in complex systems; (2) It enables a thorough analysis and management of the processes and their interactions in order to minimize costs and risk; and (3) the matrix format is suitable for computerizing.According to Steward (1981), the essence of DSM consists of developing a square matrix, which rows and columns represent the separate project tasks/stages.In the matrix cells (except those of the main diagonal) the link/dependence of a given task with/on another or others is marked.The empty cells indicate an absence of such dependence.
A more thorough study of the literature worldwide in this context shows that the majority of authors (Browning & Eppinger, 2002;McCord & Eppinger, 1993;Panayotova, 2005;Panayotova & Andreev, 2011;Steward, 1981; and so on) are considering the task relationships as depicted on following 3 types (see Figure 2): a) No link / dependence between tasks (both tasks are independent from each other); b) Sequential / one-way dependence (e.g.task B needs the result of / information from task A); c) Two-way dependence or interdependence -both tasks use each other's results / information -iteration process (cycle).
Although this representation generally satisfies the logic for DSM constructing, it is particularly not appropriate enough for the study of the relationship with customers during project process.Above all, there is a need for clarification of the cause-effect links/relationships among project tasks and the way customer intervention in any of them would affect the performance of others, as well as the project as a whole.
For example, the subject of discussion in case a) can be a completely independent task A that does not interact with any of the rest project tasks and thus the intervention of the customer here in no way would affect the project implementation and management.However, tasks A and B can also be part of two parallel partial project paths and, although not depending on each other, they both could have an undesired influence on a subsequent task expecting their results or information flows etc.
For these reasons, it is necessary to explore different situations a task could fall in, and depending on the specifics of the particular situation, the appropriate conclusions and decisions to be made.
Therefore, for the purposes of this publication, we consider the possibilities for any project task in the following way (Figure 3).
It is obvious that, concerning availability of input/output signals (information, dependence etc.), there are four possible combinations for a particular task (Figure 4).However, in the fourth case, an individual task may or may not be part of a loop/cycle.So there are two different sub-types that require different behavior when deciding on the customer's admission.
A brief description of Figure 4 variants gives an idea for the nature of decision making considerations: 1) Separate/Independent Task (no predecessor to depend on, and no successor depending on it); 2) Final/Dependent Task (no successor depending on it).This task, though dependent on other ones, suggests relatively free customer's intervention because its result will not affect any successor task; 3) Initial/Independent Task (no predecessor to depend on) -a case opposite to the previous one; 4) Chain/Dependent Task (predecessor(s) available to depend on, and successor(s) depending on it available).The fact that the task is an intermediate link in the chain requires compliance with restrictions imposed by the predecessor one(s) and the Here, tracking the impact of the customer's intervention is easier to be analyzed and more predictable; b) Closed Loop Chain (consisting of two or more tasks; also there could be more than one loop a particular task is involved in).In this case the risk increases, depending on how many tasks are in the loop, because of the very fact that the decision maker must make prior assumptions about how the process will develop and, according to this, start accomplishing from a given task in the loop.Subsequently, if necessary, rework is done and corrections are made.
Besides above considerations, addressing individual task types, different types of relationship that might occur among them have also to be taken into account.In Table 1, the possibilities for combinations between different task types are provided, in their capacity of predecessors on the one hand (rows), and successors on the other (columns).It should also be stressed here that the following eliminations are made.
-Task type 1 should be excluded from this kind of consideration -both in its capacity of predecessor and successor, since no dependency exists here; -Task type 2 -in its capacity of predecessor, since this task is a "final" one; -Task type 3 -in its capacity of successor, since this task is an "initial" one.
Taking into account above assumption, the following matrix is derived: Each one of the 49 situations from Table 1 offers different specifics of company behavior when deciding on the customer admission strategy.For example, the situation 1 forms an independent "set" of two or more tasks that could be considered as a work package, entirely separated from the rest of project activities, and thereforeeasier to deal with, when customer intervention is foreseen to be realized during completion of tasks and/or the work package as a whole; situation  implies an entering of one or more intermediate chain tasks into a loop, so this might have an (undesirable) impact on the assumptions/inputs and constraints for executing the loop itself, and so on.

Table 1. Situations defined by the combinations among project task types (designations according to Figure 4)
Our intention in this publication is to introduce some general considerations and guidelines, and to elaborate a generalized model/algorithm for that as well.In future publication(s), we plan to go into details and discuss the tools to be used in various situations.

THE APPROACH FOR CUSTOMER ADMISSION IN PROJECT IMPLEMENTATION PROCESS
The main idea of the approach proposed here can be extracted out of the following general rules (designations according to Figure 4): 1) Type 1-tasks (separate / entirely independent) can be executed simultaneously or in any order among themselves without disturbing the overall structure of the project processes.It may therefore be expected that the influence of the customer on any of them will not affect the execution of the other(s).The decision about the way of completing such a task could therefore be based on considerations, such as: (i) launch an as-early-as-possible start, regarding the uncertainty in the evaluation of the task duration, or (ii) launch an as-late-as-possible completion of the task, given the risk in cost estimations.In any way, the customer admission is only to be a subject of overall project timeline, cost and/or other similar considerations.
2) Type 2-tasks (final, dependent) to a very large extent could be seen as the type 1 tasks, because there is no successor to depend on it.Therefore a relatively high degree of freedom to act is allowed here, consistent with the constraints and conditions posed on the task by its predecessor(s).
3) Type 3-tasks (initial, partially independent) -although the task does not depend on others, its output, influenced to the corresponding degree by the customer involvement, will have a direct impact on its successor(s).
4) Type 4a-tasks (chain / intermediate, dependent) must be examined in order to be defined (i) what the indirect effect on the dependent successor(s) will be when the customer determines the performance of the one it depends on, and (ii) what implications this may have on the other tasks/processes.There are publications (for example: Eppinger at al., 1994;Panayotova, 2005) discussing these issues and proposing evaluation criteria such as "Speed of Process Development", "Tasks Sensitivity" etc., that could help in choosing what strategy to use (to allow customer admission or not, and to what extent).
5) Type 4b-tasks (closed loop chain, interdependent), because of their very nature, should be summarized into group(s), due to the complex interactions among them and the presence of one or more closed loops/cycles therein.In this case, the most appropriate strategy is not to allow the customer to influence any task within the group, since his/her intervention will certainly lead to additional confusions.Therefore, all interdependent tasks from a given loop must be considered as a whole one -summary / composite task, in terms of customer intervention.After this is done, the composite task should be analyzed and classified as one of task types 1 to 4a.Eventually, according to the type defined, the company will act according to one of above mentioned four ways.

THE ALGORITHM FOR CUSTOMER ADMISSION PRESCRIBING
According to the approach already proposed, the procedure begins with the steps for optimizing the arrangement of project tasks in the DSM, defined by Steward (1981).
Step 1: Arrange Project Tasks -DSM Partitioning Having in mind the objective of this publication, the procedure details, which are well known, are not discussed here.Instead, an example is shown in following figures.Following Stewart's algorithm steps, we get to the partitioned matrix shown on Figure 6.
The following should be emphasized here: -Tasks B and D are Type 3-tasks (empty rows).They are independent of each other; -C, E and H are Type 2-tasks (empty columns) -also independent of each other; -F, K and A are Type 4a-tasks (intermediate ones); -J, I and G are Type 4b-tasks (interdependent ones); -There is no Type 1-task.
Step 2: Group Interdependent Tasks into Blocks / Composite Tasks According to Rule 5, the customer should not be allowed to intervene inside the block(s) consisting of interdependent tasks.Therefore each such block is seen as a single task in relation to customer's intervention.The block from the example given here, is conditionally named as task "JIG" on Figure 7 and obviously it is of 4a type.
Bellow, the corresponding rule is pointed to be applied to each one of the tasks: -Tasks B and D -Rule 3; -Tasks C, E and H -Rule 2; -Tasks F, K, A and JIG -Rule 4.
On Figure 8, an Activity-On-Node/AON graphic equivalent of the matrix is provided, which could serve as a visual presentation during discussions with the customer regarding the cause-effect relationships between his/her intervention at a point of consideration and the project implementation process.

Step 3: Define the Internal Priority Inside Each Group of Interdependent Tasks
Since DSM provides only limited information about the direction of the internal project interactions, a method is needed by which these interactions may obtain a quantitative evaluation (e.g.weightings) for their priority, i.e. the binary DSM from Figure 6 is to be converted into a numerical one.This requires a quantitative study and measurement (where possible) of the degree of interaction among type-4btasks in DSM, in order to be defined where the dependency is stronger or the information is more important, etc.
As a method for multi-criteria decision making, the Analytical Hierarchy Process (AHP) (Panayotova, 2005;Saaty, 1980) can be applied here.Besides being an effective method for comparing alternative design concepts, it can certainly be used for arranging interdependent tasks under different pre-established priority criteria, as for each criterion may be referred subcriteria and so on.As already mentioned, this also will be a subject of our further publication(s).However, a very important note here is that the complex structure of DSM and inside interactions in the blocks of interdependent tasks must be properly and thoroughly analyzed from the very beginning. Step

4: Analyze Cause-Effect Relationship of Customer Intervention
When discussing the reasons and intentions leading to customer involvement into the project processes performing, a special attention is to be paid to the causeeffect relationship among different tasks and thereby the influence on them, caused by the customer intervention.This is why, every undesirable effect, or indirect frustrating of project schedule or whatever else concerning the project itself, must be predicted, when defining whether to allow customer's intervention at the point of consideration or not.
This analysis has also to be made according to the task type, i.e.: -Type-1-tasks should be regarded in the light of overall project constraints and considerations; -Type-2-tasks -according to the constraints and influence on them posed by their predecessors; -Type-3-tasks -according to consequences that they will provoke onto their successors by letting the customers define the way task is performed; -Type-4a-tasks -both depend on constraints posed on them by their predecessors, as well as influence their successors; and -Type-4b-tasks -customer intervention forbidden inside the loop!

THE ALGORITHM FLOWCHART
On the following figure, the flowchart of the algorithm steps and dependencies discussed so far is presented in Figure 9.

CONCLUSIONS AND FUTURE WORK DIRECTIONS
Project Management tools help a lot in implementing new concepts and approaches that provide greater customer involvement in added value creating.This applies to almost all areas of life, no matter if the customer is an individual, a business, or a public institution.
In the present paper, we introduce an approach that helps in defining places throughout the project implementation process, the interaction with the customer is to be realized at.By applying it, recommendations are made for defining limits of customer intervention on the basis of interdependencies among project activities during project processes studying.As a major tool in this model, Design Structure Matrix is used, but with some improvements in its approach concerning the interpretation of task types and their relationships, as well as some directions are discussed about using Analytical Hierarchy Process.Primarily, our intention here has been to introduce the approach itself for choosing a customer admission strategy, as well as a generalized algorithm to do this.In our future publication(s), we plan to discuss and elaborate appropriate tools to be used in various situations, the relationship with customers could fall in.

Figure 2 .
Figure 2. Graph configurations of relationships and DSM representation

Figure 5 .
Figure 5.Initial appearance of project tasks in the design structure matrix

Figure 8 .
Figure 8. AON-graph of the project