SDM 5002 SYSTEMS ENGINEERING

Technical Document Change Control System

(Business Process Re-engineering)

TEAM MEMBERS
CHONG KHAI SIN (HT072850H)
GOH SIONG TECK (HT072853R)
HOSSAM EL SHENAWY (HT072894R)
LIM CHING WU, LESLIE (HT063039Y)
LIM CHUN PENG, ALVIN (HT063324Y)
TAN SUNG CHYN (HT062932E)
Division of Engineering & Technology Management
SDM5002 System Engineering

Content

1. OBJECTIVE........................................................................................................................................ 3
2. METHODOLOGY............................................................................................................................... 3
3. SELECTION AND IDENTIFICATION ............................................................................................. 4
4. PROCESS MAPPING ....................................................................................................................... 4
4.1 ANALYSIS OF CURRENT PROCESS ............................................................................................. 7
4.2 REVIEWING ON THE MANUAL REVISION PROCESS ...................................................................... 7
4.3 REVIEWING ON THE FORMAL REVISION PROCESS ...................................................................... 7
4.4 ROOT CAUSE ANALYSIS ............................................................................................................. 8
5. THE REDESIGN................................................................................................................................10
5.1 IMPLEMENTATION .......................................................................................................................10
5.2 ANALYSIS OF THE NEW PROCESS .............................................................................................13
5.3 POSSIBLE RESPONSES FROM THE STAKEHOLDERS .................................................................13
6. RECOMMENDATIONS....................................................................................................................14
7. CONCLUSION...................................................................................................................................14

2
Division of Engineering & Technology Management
SDM5002 System Engineering

1. Objective

Business process re-engineering (BPR) is a management approach aiming at

improvements by means of elevating efficiency and effectiveness of the processes that
exist within and across organizations. According to Hammer and Champy, it is the
fundamental rethinking and radical redesign of business processes to bring about
dramatic improvements in critical, contemporary measures of performance, such as cost,
quality, service, and speed [1]. The BPR project allowed the team to understand and
practice some of the key activities in the BPR methodology. This report documents the
different phases and the results of the BPR project. It highlights the methodology used,
each of the steps taken to map the processes, the analysis done, as well as the key
considerations and the implementation of the redesigned process.

2. Methodology

Generally, there are various approaches to BPR with relatively few differences on
conceptual level. They all contain the phases Initiation, Analysis, Design, Implementation
and deployment. Most of the consulting firms such as Boston Consulting Group,
McKinsey, Bain, and Andersen Consulting follow these concepts in their reengineering
effort. However, there are different emphases on each of these phases. The methods
and tools used within different methodological stages are mostly identical. In this project,
the 6-Step Approach taught in the lecture was practiced [2]. Figure 1 shows the various
phases in this approach.

Figure 1: 6-Step BPR Approach.

In this project, only the first 3 phases were practiced. The rest of the report mainly
documents the activities and results from these three phases.

3
Division of Engineering & Technology Management
SDM5002 System Engineering

3. Selection and Identification

The process identified is the procedure on requesting for change of technical documents
used in one of the group members’ company. The reason for selection of this process
was that there was a domain expert among the team, who could provide both the
general overview and the necessary details required to analyse the process. In addition,
the process is relatively easier to understand and generic to other companies for better
appreciation.

The customers in this process are the personnel who use the revised documents. They
are mainly the operators. However, engineers, including specifically the Quality
Assurance (QA) engineers, also use the document.

There was a need to review this process as there was relatively high and constant
demand for change request. This process took up a substantial amount of the engineers’
time and prevented them from attending to other value-adding activities, such as project
developments.

From the brief overview, it was noted that the process is manual driven and highly
inefficient. The group suspected that a great amount of savings could be achieved
through a detailed investigation using the BPR methodology. A stretched target of 80%
total process time reduction was set.

4. Process Mapping
Figure 2 shows the original process of the Technical Document Change Request
System.

The customer who prompts the change can be an operator, an engineer or a QA

engineer. The technical difficulty of each change request varies. Therefore, the time
required to review and amend the document varies too. In order to simplify the analysis,
most frequent occurrences were only considered:

1. Operator/Engineer as the customer - Whenever someone prompts the

request change, the Engineer will review whether to carry out a formal or an
informal (manual) revision. The advantage of a manual revision is that there is
immediate response to address the urgent concern. A manual revision also
means that the engineer can only make limited amendments. Hence, it is always
associated with simple issues such as providing small amount of additional data
or typing errors. In the event of serious errors or the requirement of a substantial
change to the documentation, a formal revision is stipulated to generate a new
version of the documents. During formal revision, the previous manual
amendments (if any) embedded within the documents are also being formalized.
If formal revision is involved, the Engineer will also check with the QA Engineer
for any latest revision to the technical references that the documents are based
upon. Updates to the technical references occur on a quarterly basis and are

4
Division of Engineering & Technology Management
SDM5002 System Engineering

usually editorial or minor technical changes. To complicate matters, a single set

of technical documents may cross references to different sets of technical
references which might be released either at the same time or within a few
weeks.

2. QA Engineer as customer - Based on the swim lane chart in Figure 2,

group members enquired the rationale behind getting the QA engineer to review
and notify changes even when the requestor is the QA Engineer him/herself. The
reason is that Engineer takes time to review the change request. It is possible
that during this review period, another technical reference which the technical
document is based on is also affected. Hence, upon receiving the amended
document from the Engineer, QA Engineer will still check whether any of the
other technical references are affected.

5
Division of Engineering & Technology Management
SDM5002 System Engineering

End End
Start Discover Error

Customer

Request Formal Copy

Amended Copy
Change

Review Error Distribute (BE)

(BE) Distribute (BE)

No (20%) Formal (20%)

Manual or
Batch or not? Stamp and
Formal?
Stamp and Sign (WA)
Yes (80%) Sign (WA)
Manual
(80%)

Print and Sign

Edit Softcopy
File Master Delay New Revision
Document (VA)
Copy (WA) (VA) File Obsolete
Delay Copy (WA)
Engineering
(5 PAX)
Photocopy
Document
(WA)
Edit Hardcopy
Document (VA) File Master
Copy (WA)

Delay Photocopy
(WA)

No (20%)
Batch or not?
Delay
Yes Review and
(80%) Delay Notify Change
(BE) Verify Error
Quality (BE)
Assurance Verify Error
Delay
(1 PAX) (BE)

Approve?
Yes
(90%) No (10%) Yes (90%)
Approve?
No
(10%)

Figure 2: Current Technical Document Change Request Process. (Please Refer to Appendix A for detailed information of the process)

6
Division of Engineering & Technology Management
SDM5002 System Engineering

4.1 Analysis of Current Process

From the process map of the current process, the following attributes are calculated:

Number of Handoffs 11
Number of check/control activities 5

Manual Revision

Total time of value-adding activities 10 minutes

Total cycle time 240 minutes (4 hours)
Hand-off ratio (# of handoffs / # of 5/1 = 5
VA steps)
Delay influence ( Total delay time / 30/240 = 0.125
Total cycle time)
% of VA time vs total cycle time 4%

Formal Revision

Total time of value-adding activities 120 minutes

Total cycle time 960 minutes (2 working
days)
Hand-off ratio 11/ 2 = 5.5
Delay influence 75/ 240 = 0.3125
% of VA time vs total cycle time 12.5%

4.2 Reviewing on the manual revision process

From interview with the domain expert (an engineer), the group understood that the
manual change was the preferred choice even though Value-adding Activity (VA) is only
4%. This was because it was a quick and responsive way to address the request. An
estimation of 60 technical requests were received every month and majority of them will
be manually revised. Although the manual process was considered “quick” relative to the
formal process, the VA is too small and indicates a lot of wastage of the Engineer’s time
especially taking into account the relatively large volume of request changes.

4.3 Reviewing on the formal revision process

In terms of VA, it is much higher than the manual process at 12.5%. However, the total
cycle time for this process is approximately two working days. This can be shortened.

In general, although only two parties are involved in the revision process, the number of
hand-offs is relatively high (five hand-offs for a straightforward manual amendment
process). There are also a number of delays (batching operations) that indicates an
inefficient process.

7
Division of Engineering & Technology Management
SDM5002 System Engineering

4.4 Root Cause Analysis

Figure 3 shows the Fishbone diagram used to derive the causes for the slow and
inefficient process.

Figure 3: Fishbone Diagram of the root causes for the slow and inefficient process.

4.4.1 System/ Process – from the process model, it can be seen that there are a
series of checks and rechecks. As the company is operating in a mission critical industry
with tight regulations, it is mandatory to have personnel from the quality function to serve
as an independent party to counter check the work. Due to this restriction, there will be a
loop that has to be built into the design. There are two possible ways to resolve a
technical change request, depending on the Engineer’s opinion. This is fairly
complicated and there is room for improvement to make the implementation easier.

4.4.2 Technology – Based on feedback from the Domain expert, there is a general
frustration while carrying out this task due to excessive handling of paperwork. A portion
of time is spent on signing on the original copies, photocopying/ date stamping/ signing
and delivering distribution copies. The non-value added activities take up a portion of the
engineers’ time which can otherwise be used for process improvement or new project
development. There can also be ways to reduce or eliminate physical traveling for
document delivery.

4.4.3 People – The process model shows a tendency for the engineers to batch their
work. Upon probing, it was revealed that this was due to multi-tasking. The engineers
were using batching to reduce the frequency of carrying out a technical change request
so that they could free up more time for other duties. It is also noted that while there are
five engineers capable of carrying out the technical change request, only one quality
engineer is assigned to this work. Feedback from the domain expert revealed that the
reason was that engineers were doing the majority of the work while the quality
engineer’s involvement was only in the verification and counter signing stage. Moreover,
the company has a limited number of quality engineers. Due to other work commitment,

8
Division of Engineering & Technology Management
SDM5002 System Engineering

there is also a tendency for the quality engineer to carry out batching which results in a
typical 2 days cycle time for a formal revision and 4 hours for a manual revision.

4.4.4 Method – Based on the inputs gathered, the entire work process is highly
“Manual” and labor intensive. This manual process coupled with limited manpower and
pressure of multi-tasking to carry out the technical change seem to be the reason for the
existence of the formal and manual revision methods, and the prevalence of using
batching to free up time.

9
Division of Engineering & Technology Management
SDM5002 System Engineering

5. The Redesign

Upon identifying the problems in the present system, the team redesigned the process
with the following principles:

1. Capture information once and at the source – Amendments are made to the
manual and formal copies separately, and photocopied for end users when
the changes are verified. These changes should be made only to one copy at
the start of the process and the same copy made available to the end users.

2. Integrate repeated activities instead of integrating their results – The manual

and formal amendments activities are almost identical. They should be
integrated in a way that the result is still the same for the end users.

3. Have those who use the output of the process perform the process – Most of
the waste activities identified involves processing of the information in the
proper format and distributing to the end users even when the changes and
verifications are finalized. The new process should minimize these activities
or transfer the responsibilities to the end users.

4. Organise information flow in a timely and effective fashion to remove need for
intentional delays – There are six intentional batch activities in the current
process. These delays increase the total cycle time and reflect the
inefficiency of the information flow.

5. Organise around outcomes, not tasks – In the current process, after the QA
has verified the changes, there are still several activities before the end users
receive the new technical document. The new process should be designed in
a way where the outcome of the process is delivered straight to the end users.

Figure 4 shows the redesigned process.

5.1 Implementation

The proposed new redesign of the process has an IT system in its heart to implement
the technical document version control. As it is an industry requirement to have at least
two persons involved (one to change, the other to verify), hence, the personnel involved
in the new process will remain the same. Some of the features of this IT system include
the following:

1. Digital copies of the technical documents will be kept in system.

2. Access control is implemented for making changes to it. Users from the
Engineering department will be required to log in before they are granted
access to amend the documents.

3. Any changes once confirmed are automatically time stamped and digitally
signed based on the log in profile.

10
Division of Engineering & Technology Management
SDM5002 System Engineering

4. Priority levels can be set to each change tasked.

5. Tasks for verification by QA team will be automatically notified via the email
system once the Engineering team has submitted the changes.

6. Similar access control is implemented for the verification of changes by the

QA team. The tasks will be presented to them via a priority queue to ensure
that the most urgent changes are verified and no task is too small to be
delayed.

7. Any changes once verified are automatically time stamped and digitally
signed based on the log in profile.

8. Any changes which are not approved will be routed back to the Engineering
department. This is notified via the email system and presented in priority
queues as well.

9. All verified changes will be automatically printed out at the printer located at
the workshop where the end users are. Only the pages to be replaced will be
printed. Number of copies printed will be according to the number of technical
teams in the workshop.

10. The technical teams are notified via the public announcement system will be
asked to collect the printouts from the printer to replace their copies in their
binders.

11
Division of Engineering & Technology Management
SDM5002 System Engineering

Customer Self
Start Discover Error Collect Printout
to File in End
Formal
Document

Customer Request
Change Automatic
Printout at 0.1 hrs –
Workshop and estimation for
Generate max printing per
Notification to workstation
Customer

1 hr Review Error
(BE)

Embedded in Edit Error &

the amendment Sign Digitally
process = 0 (VA)

Engineering
(5 PAX)
Send
Send upon Notification to
Engineers’ QA of Changed
approval, Document in a
negligible time System Priority
(Mouse click) Queue
(BE)

2.3 hr – refer to Verify Error Sign Digitally Embedded in

appendix B for (BE) (BE) the amendment
details process = 0
Quality
No
Assurance
(10%)
(1 PAX) Yes
(90%)
Approve?

Figure 4: Redesigned process. (Please refer to appendix B for calculation details)

12
Division of Engineering & Technology Management
SDM5002 System Engineering

5.2 Analysis of the New Process

Number of Handoffs 5
Number of check/control activities 1
Total time of value-adding activities 60 minutes
Total cycle time 204 minutes (3.4 hrs)
Hand-off ratio (# of handoffs / # of 5/1 = 5
VA steps)
Delay influence ( Total delay time / 0
Total cycle time)
% of VA time vs total cycle time 60/204 = 30%

1. Number of batching is reduced. This reduces overall process time and increases
efficiency.

2. The entire process is simplified and standardized. This will give rise to clarity of
task execution and promote quality work. The total process time has been
reduced from 4 hours (for manual revision) and 2 working days (for formal
revision) to 3.4 hours, with the elimination of the manual revision. The possibility
of not incorporating the previous manual amendment information during the
subsequent formal revision due to carelessness can also be eliminated.
Shortening respond time to the technical change significantly will improve
customer’s satisfaction. The engineers will also experience a significant reduction
in the paperwork.

3. The total process time is reduced from 6.4 hrs to 3.4hrs. The 6.4hrs for the old
process is obtained from the ratio of 80% of the cases require manual
amendment ( 4hrs) & 20% of the remaining cases requiring formal revision ( 16
hrs or 960 mins)

5.3 Possible Responses from the Stakeholders

Operators may need to familiarize with the retrieving the printout from the printer tray
instead on being delivered to them.

This is a simple way of processing the change requests for the engineers. Hence, they
are unlikely to resist the new process and will welcome the work reduction in terms of
delivering the documents, the photocopying, and stamping activities. There is no longer
a need to sign on every page of the documents due to the feature of digital signature.

There is minimum impact and workload reduction to the QA engineers. However, they
do not need to countersign every single page of the amended/ revised document.

13
Division of Engineering & Technology Management
SDM5002 System Engineering

6. Recommendations
Senior management may be concerned on potential large investments required for
enhancing the IT infrastructure. This is a radical change from a majorly hardcopy
process into a majorly softcopy process.

Departmental managers must first convince the senior management with the quantitative
advantages found in the analysis of the new process. In a top-down approach,
endorsement from the senior management will help to ensure smooth implementation
and cooperation between different departments involved.

A well-defined time-line and milestones should also be defined for the implementation,
and responsibilities should be clearly defined.

Upon complete implementation, deployment of the new process should be staged in

parallel with the old system for at least one month. This will ensure that any problems
and bugs that might arise will be detected early on before the new system is adopted.

Post-implementation review should also be conducted with the relevant metrics defined
during the process re-engineering. Feedbacks from engineers and customers are also
necessary for any minor improvement to the new process if necessary.

7. Conclusion
The industry is highly competitive. The company will not be able to afford assigning
resources to non-value added activities. The problem is compounded by manpower
shortages. Hiring lower skilled temporary workers can help to shift the non-value work
away from the engineers but does not reduce the overall workload in the process. Cost
will still increase.

Project development time is lengthened due to the commitment of engineering resources

to such activities. Through this BPR exercise, the system can be revamped. A significant
amount of engineering resources can be freed to support the company’s customers. The
amount of time the engineers spend on this process can be reduced by from 50% to the
projected 25%. This is equivalent to the creation of an additional engineering resource.
The time freed will enable the engineers for new product development and process
improvement.

As the company continues to diversify its product offerings in order to reduce its
dependency on particular OEM engines and component types, the complexity of
maintaining such a diversity of product offerings is growing accordingly. At the last count,
the 5 engineers are supporting a product mix of 500 items. As the company is currently
profitable and looking at ways to improve the sales further, a robust documentation
system is essential to further this goal. Through the leverage on inexpensive
technologies, the BPR project can better align the company towards meeting its goals.

14
Division of Engineering & Technology Management
SDM5002 System Engineering

References

[1] M. Hammer, J. Champy, Reengineering the Corporation: A Manifesto for

Business Revolution, Harper Business, 1993.

[2] Y. W. Ku, Business Process Reengineering (BPR), SDM5002 System

Engineering Lecture Slides, NUS, 2008.

R-1
Division of Engineering & Technology Management
SDM5002 System Engineering

Appendix A - The Current Process Swim Lane Diagram Capture

During Exercise

The values for calculation are obtained from this swim lane.

A-1
Division of Engineering & Technology Management
SDM5002 System Engineering

Appendix B – Calculations for the processes

The calculation is based on data provided in Appendix A. This will be verified by data
collection after the implementation of the proposed solution.

Existing Process

Manual revision = 4 hrs

Formal revision = 16 hrs
Using the ratio of 80% manual & 20% formal,

Total process time (average) consider both manual & formal revision = 0.8*4 + 0.2*16 =
6.4 hrs

This value is used to compare the improvement by the redesign process as in the
redesign process, the choice for manual & formal revision is standardized to formal and
using the ratio to approximate the time taken to process an “average request”.

Redesign Process
To simplify calculation, only the steps remain after elimination with the same time data is
used to provide a rough savings projection. (Data is extracted from the equivalent
process in Appendix A)

Manual process (Engineering editing) component equivalent

(Manual) Process to review error = 1/2 hr

(Manual) Process to edit docs = 1/6 hr
(Manual) Total Process Time for edit = ½ + 1/6 = 2/3 hrs
(Formal) total process component equivalent = 2 hr

Estimated redesign process time for engineering = 0.8*(2/3) + 0.2*2 = 1 hr

Manual process (QA reviewing) component equivalent

(Manual) Process for QA to review: 1 5/6 hr

(Formal) Process for QA to review: 4 hr

Estimated redesign process time for QA = 0.8(1 5/6) + 0.2(4) = 2.3

Estimated redesign process time for printing of revised documents = 0.1 hr

Estimated total process time for redesign process = 1 + 2.3 + 0.1 = 3.4hr,

B-1