Minor site enhancement
Every organization has the requirement of ordering a small amount of loosely defined work with a fixed number of hours. An example of that is a minor site enhancement which is a minor update of a website.
The hours are fixed at a maximum amount of hours. The actual steps of the work are not usually defined in these requests. The steps are the responsibility of the specialists assigned to the fulfillment team. Typically these are requests that are not completely standardized, but are a too small to handle with RFS (Request for Service) requests.
The requests for a minor update of code or website is used as an example of this type of request. Typically, the code is developed and tested in a dedicated environment (E1) by fulfillment specialists (developers), tested in a Test environment (E2) and finally deployed and tested in a production environment (E3). The fulfillment workflows in this document depict this kind of rollout.
The authorization process of the minor site enhancement request solicits approval from the requester's manager as well as the approver of the delivery team. The tasks of the approvers include verification of funding for the request. Multiple approvers might be required in some organizations. Notifications are sent to the service requisition user indicating the disposition of the approval request with reason codes.
- Approve or disapprove request
- Close request
- Minor website enhancements. Virtually all businesses have websites that require updates, such as price changes, may be routine, others might be minor cosmetic or news updates where the work is relatively simple. In all cases, the labor is capped at some predefined effort, usually around 25 hours.
- Software evaluation. Most large businesses have a defined set of products that are imaged on the workstations. Frequently some departments have special needs for new software to be added for business purposes, but they are unclear as to whether there are compatibility problems with other software in the system. These requests typically have a software group provide an independent evaluation of software compatibility.
- Test of some systems. This is used for a quick, independent evaluation of a system ex. from a security or corporate compliance standpoint.
- Special events coordination. This is used for service requests for special events, also with a maximum labor charge.
- Some types of minor facility requests. Requests that are too small to be handled as normal IMAC requests are categorized as minor site enhancement requests.
- Open E2 CMR record (Fulfillment Specialist).
- Create code (Fulfillment Specialist).
- Deploy Code to E2 (Fulfillment Specialist).
- Validate Changes Deployed into E2 (QA Specialist). Note: Set DPCODEE2 in task specification to 0 or 1. If validation fails, the process returns to step 1.
- Open CMR in E3 (Fulfillment Specialist).
- Deploy Code to E3 Environment (Fulfillment Specialist).
- Mark CMR complete (Fulfillment Specialist).
- Validate Changes Deployed into E3 (QA Specialist).Note: Set DPCODEE2 in task specification to 0 or 1. If validation fails, the process skips to step 10.
- Close CMR (Fulfillment Specialist).Note: This is the final step if validation is successful.
- Backout Changes (Fulfillment Specialist).
- Close CMR (Fulfillment Specialist).
The resource assignment process completes the analyst's assignment of the service request to a specialist or the team queue.
- Notify requester to test.
|Responsibilities related to Minor Site Enhancement Requests
|Service Requisition User
|Enters service request information for a Minor Site Enhancement. Completes verification test of update when notified by Fulfillment Specialist.
|Receives e-mail asking for an approval for a Minor Site Enhancement. Updates service request accordingly. Assigns task to a fulfillment specialist.
|Receives service request assignment email notification, determines detail is sufficient and completes implementation of request. Monitors testing and when done, marks request as complete.
|Tests and validates code in E2 and E3 environment.
- A parent work order (not shown)
- PMSC_0018A : job plan with task precedence relationships between them (as shown in the preceding schematic – applied to the work order to create a work plan)
- Flow control activated on the work order and job plan tasks (not shown)
- Data Relationships :
- WORKORDERSPEC_DPCODEE2 : relates classification data attribute DPCODEE2 to the WorkOrderSpec instance.
- WORKORDERSPEC_DPCODEE2 : relates classification data attribute DPCODEE3 to the WorkOrderSpec instance.
- PMSC_CB : data attribute classification for DPCODEE2 and DPCODEE3 logic switches Set value: 0 (No branch) 1 (Yes branch)
- workflows active on the woactivity objects :
- PMSC18_CB1 : the Yes branch conditional branching workflow for Deploy E2 Condition: :parent.WORKORDERSPEC_DPCODEE2.numvalue = 1
- PMSC18_CB2 : the No branch conditional branching workflow for Deploy E2
- PMSC18_CB3 : the Yes branch conditional branching workflow for Deploy E3
- PMSC18_CB4 : the No branch conditional branching workflow for Deploy E3
- Task actions :
- PMSC_SCB1WF: each task in the YES conditional branch for E2 Deploy will execute this action to start a short workflow.
- PMSC_SCB2WF: each task in the NO conditional branch for E2 Deploy will execute this action to start a short workflow.
- PMSC_SCB3WF: each task in the YES conditional branch for E3 Deploy will execute this action to start a short workflow.
- PMSC_SCB4WF: each task in the NO conditional branch for E3 Deploy will execute this action to start a short workflow.
- PMSC_PB: which executes for the ‘No' branch condition
- PMSC_COMP: marks each ‘No' branch task COMPLETE
The workflows have a condition that branches true or false based on the data switch (DPCODEE2 or DPCODEE3) setting. The condition is: :parent.WORKORDERSPEC_DPCODEE2.numvalue = 1 (also DPCODEE3) If true: executes Yes workflow branch. Task remains in the in-progress status. :parent.WORKORDERSPEC_DPCODEE2.numvalue = 0 (also DPCODEE3) If false: runs a task status change to complete.
The parent work order is set into progress. Flow control starts its first eligible task, 10.
Tasks 10, 20, 30 create and deploy Code to E2 server.
Task 40 owner must verify the E2 code deploy before changing the task status to complete and set specification value DPCODEE2 true (1) or false (2) accordingly before completing Task 40.
Task 3 owner must verify the E2 code deploy before changing the task status to complete and set specification value DPCODEE2true or false accordingly before completing Task 40.
Flow control sets tasks 5 and 4.1 in progress simultaneously and also starts workflow on them immediately.
Tasks 5.0, 6.0, 7.0, or 4.1, 4.2 are either all marked complete or the first node is marked in progress automatically by workflow.
Task 8.0 owner must verify the E3 code deploy before changing the task status to complete and set specification value DPCODEE3 true (1) or false (2) accordingly before completing the Task Flow control sets tasks 9.0 and 9.1 in progress simultaneously. Workflow runs the same way as described in the preceding text.
Flow control detects the end of the task set and rolls the completion of 9.2 up to the parent work order, closing out the work set with this final status change of the parent.