Using the concept of modelling for this case was a vital element in addressing the areas for improvement in the car servicing company as well as to provide a better understanding of the organizations operations. Using various concepts of modelling, we try to explain the occurrences of faults and loopholes in a big business organization. Using models as a tool can help visualize the organization by representing the entire system from a top view perspective.
Our group utilized the modelling process in order to have an illustration of the organization in order to assess the situation. Along the way, the group has been able to analyze the handling process of stakeholders in the organization and improve the loopholes therein. In the case we ended up in justifying that there should be a transition from the Business Model to the Requirements Model. The shift of model is justified in tables 5 and 6 where most of the handling appointment processes are given to a back office. These processes are the initial receiving of customer request, asking for customer details, checking of fee slots, and the negotiation of appointments. The focus of the Requirements Model shifts the importance from just setting up appointments to maintaining a system that would value efficiency.
Service representation is important in the car service case. The process we used is initiated by customer request for an appointment. The group made the assumption that the office clerk will communicate with the customer and we didnt need to model any communication external to the process itself taking into account that this communication would exist between the office clerk and the back office. This was one of the primary perceptions that I had upon first seeing the case. This perception I had influenced the creation of models by our group and was kept as a primary contribution from my part.
On the other hand, the possible system use case revolves around the automation of events andor activities that is tasked for the Service Engineer and the Office Clerk. These activities which would be automated are the entering of additional work and viewing of additional work loads. However, the contacting and requesting of customer authorization remains non-automated since this would remain better off as such. Table 6 can be used in the assessment of the changes in the model from the business model to the requirements model based on the previous assumption. This would support the client behavior and at the same time protect the organization interests while creating a smooth atmosphere for the customer. The requirements model also encompasses the important tasks and responsibilities of store clerks in order to provide the customers a better and efficient service. Furthermore, the requirements model process will be initiated by servicing engineering if additional work is required. This transition was the primary consideration in creating the model for this case.
The group held several workshops before each seminar in trying to answer how the transition could be implemented in the organization without affecting the service rendered to customers while doing so. Furthermore, we also assumed various situations which could affect the implementation of the transition to the requirements model. In the end, our group thought that the primary assumption for the case should be that the customer pays for a quality service that would meet their expectations and the value for their money.
For instance, the customer would make appointments for car servicing and in the process provides information and personal details. During the time of setting up such appointment, the customer is not yet required to provide the payment details. The payment details will only be looked upon when the customer is already on the day of appointment and already has hisher car supposedly ready for servicing. The risk obtained from this situation is that when the payment details do not satisfy the company standards, the customer get turned away after the setting of the appointment date. In order to provide a better service and a more rational way of verifying payment information, details should be retrieved and should be verified first prior to the signing of the service contract in order to minimize the delay even in the backing out of the customer due to the inability of the organization to check payment information. This process flow is detailed by the group in Figure 3.
The entire group attended the workshops in order to address the need for transition from the business model to the requirement model. In the workshops each team member was asked about what they individually perceive about the case and each detailed the work that ought to be done. One of the members talked about the computer system used in the transactions which he said is a vital component of the transactions wherein the manual aspect of the transaction was smooth and the computer system was the problem. We started with the class diagram first because we wanted to model all the entity classes, since some of these classes and their operations will be used in the sequence diagram. The group took several more perspectives before arriving at a common ground which we believe would suit the organization in consideration.
There was also some difficulty with some of the team members because some find the case details complicated and got lost along the way when some of the members start giving in their perspectives. The group then was able to explain each ones perceptions on the case and helped those members who find the case confusing. Particularly, there were discussions on the pre-conditions within the transition from the business model to the requirements model.
This includes logging-on to the system since it is already automated and that the customer details have been retrieved from customer and the office clerk request for customer file. Such explanations were also held outside of the usual workshops that the group had. As stated in the report, we had weekly meetings which took place 2hrs to 4hrs before our seminars from the beginning of this exercise. For the first four weeks we met up for 2 hours before the seminar where each member read DMS case study and work exercise and then drew out a rough draft of the work that was due in the seminar. We had group meetings as well as casual conversations about the case which also helped a lot in clarifying the points that we raised in solving the case. This was done by tackling the details of each system use cases that we have developed and constantly analyze important documents that we have to analyze.
Among the most important services used, the automation of the primary processes as discussed in Tables 3 and 4. In Table 3, the preparation of customer invoice involves the processes of the system prompting the clerk to input search criteria based on name or registration number. Then the clerk will input search criteria and the system will search and retrieve serviced vehicle information with associated cost. This is followed by the clerk selecting the intended job and clicks on Prepare Invoice button. Finally, the system displays customer invoice. Furthermore, this is followed by the issuing of a billing statement to the customer. This provides a clear description was provided by all team members in explaining the transition of the business model to the requirement model.
In general, the discussions were healthy and members were mature enough to admit faults and help the entire team in finishing the case. We drew out system diagrams which the group along with me like a lot. It is easy to follow the flow of activities. I contributed more on this part as I had great interest on doing this. The system diagrams are built on the assumption that the office clerk will be presented by the main menu of the system with options and of these options is preparing customer invoice which he intends to select. As discussed in Table 6, most of the workload in handling appointments will be transferred to a back office which is more efficient since it is automated.
Our group utilized the modelling process in order to have an illustration of the organization in order to assess the situation. Along the way, the group has been able to analyze the handling process of stakeholders in the organization and improve the loopholes therein. In the case we ended up in justifying that there should be a transition from the Business Model to the Requirements Model. The shift of model is justified in tables 5 and 6 where most of the handling appointment processes are given to a back office. These processes are the initial receiving of customer request, asking for customer details, checking of fee slots, and the negotiation of appointments. The focus of the Requirements Model shifts the importance from just setting up appointments to maintaining a system that would value efficiency.
Service representation is important in the car service case. The process we used is initiated by customer request for an appointment. The group made the assumption that the office clerk will communicate with the customer and we didnt need to model any communication external to the process itself taking into account that this communication would exist between the office clerk and the back office. This was one of the primary perceptions that I had upon first seeing the case. This perception I had influenced the creation of models by our group and was kept as a primary contribution from my part.
On the other hand, the possible system use case revolves around the automation of events andor activities that is tasked for the Service Engineer and the Office Clerk. These activities which would be automated are the entering of additional work and viewing of additional work loads. However, the contacting and requesting of customer authorization remains non-automated since this would remain better off as such. Table 6 can be used in the assessment of the changes in the model from the business model to the requirements model based on the previous assumption. This would support the client behavior and at the same time protect the organization interests while creating a smooth atmosphere for the customer. The requirements model also encompasses the important tasks and responsibilities of store clerks in order to provide the customers a better and efficient service. Furthermore, the requirements model process will be initiated by servicing engineering if additional work is required. This transition was the primary consideration in creating the model for this case.
The group held several workshops before each seminar in trying to answer how the transition could be implemented in the organization without affecting the service rendered to customers while doing so. Furthermore, we also assumed various situations which could affect the implementation of the transition to the requirements model. In the end, our group thought that the primary assumption for the case should be that the customer pays for a quality service that would meet their expectations and the value for their money.
For instance, the customer would make appointments for car servicing and in the process provides information and personal details. During the time of setting up such appointment, the customer is not yet required to provide the payment details. The payment details will only be looked upon when the customer is already on the day of appointment and already has hisher car supposedly ready for servicing. The risk obtained from this situation is that when the payment details do not satisfy the company standards, the customer get turned away after the setting of the appointment date. In order to provide a better service and a more rational way of verifying payment information, details should be retrieved and should be verified first prior to the signing of the service contract in order to minimize the delay even in the backing out of the customer due to the inability of the organization to check payment information. This process flow is detailed by the group in Figure 3.
The entire group attended the workshops in order to address the need for transition from the business model to the requirement model. In the workshops each team member was asked about what they individually perceive about the case and each detailed the work that ought to be done. One of the members talked about the computer system used in the transactions which he said is a vital component of the transactions wherein the manual aspect of the transaction was smooth and the computer system was the problem. We started with the class diagram first because we wanted to model all the entity classes, since some of these classes and their operations will be used in the sequence diagram. The group took several more perspectives before arriving at a common ground which we believe would suit the organization in consideration.
There was also some difficulty with some of the team members because some find the case details complicated and got lost along the way when some of the members start giving in their perspectives. The group then was able to explain each ones perceptions on the case and helped those members who find the case confusing. Particularly, there were discussions on the pre-conditions within the transition from the business model to the requirements model.
This includes logging-on to the system since it is already automated and that the customer details have been retrieved from customer and the office clerk request for customer file. Such explanations were also held outside of the usual workshops that the group had. As stated in the report, we had weekly meetings which took place 2hrs to 4hrs before our seminars from the beginning of this exercise. For the first four weeks we met up for 2 hours before the seminar where each member read DMS case study and work exercise and then drew out a rough draft of the work that was due in the seminar. We had group meetings as well as casual conversations about the case which also helped a lot in clarifying the points that we raised in solving the case. This was done by tackling the details of each system use cases that we have developed and constantly analyze important documents that we have to analyze.
Among the most important services used, the automation of the primary processes as discussed in Tables 3 and 4. In Table 3, the preparation of customer invoice involves the processes of the system prompting the clerk to input search criteria based on name or registration number. Then the clerk will input search criteria and the system will search and retrieve serviced vehicle information with associated cost. This is followed by the clerk selecting the intended job and clicks on Prepare Invoice button. Finally, the system displays customer invoice. Furthermore, this is followed by the issuing of a billing statement to the customer. This provides a clear description was provided by all team members in explaining the transition of the business model to the requirement model.
In general, the discussions were healthy and members were mature enough to admit faults and help the entire team in finishing the case. We drew out system diagrams which the group along with me like a lot. It is easy to follow the flow of activities. I contributed more on this part as I had great interest on doing this. The system diagrams are built on the assumption that the office clerk will be presented by the main menu of the system with options and of these options is preparing customer invoice which he intends to select. As discussed in Table 6, most of the workload in handling appointments will be transferred to a back office which is more efficient since it is automated.
No comments:
Post a Comment