CHAPTER 3: METHOD
3.3 Method
3.3.1 Stage 1: Problem Formulation
The problem formulation stage identifies and conceptualises a research opportunity based on existing theories and technologies (see Hevner et al. 2004). Sein et al. (2011) derived the stage into two principles: practice-inspired research and theory-ingrained artefact.
Principle 1: Practice-Inspired Research
This principle emphasises viewing field problems (as opposed to theoretical puzzles) as knowledge-creation opportunities. The action design researcher should generate knowledge that can be applied to the class of problems that the specific problem exemplifies. As a result, the research activity is problem-inspired (Markus et al. 2002).
Principle 1 is covered within the research aim and objectives (Chapter 2), and the identified study context is described in the preceding section.
Principle 2: Theory-Ingrained Artefact
This principle emphasises that the artefacts created and evaluated via ADR are informed by theories. This principle suggests that, as technology designers will inscribe in the artefact theoretical traces that reflect the socio-political context of the design situation (Hanseth and Monteiro, 1997), the action design researcher actively inscribes theoretical elements in the artefact, thus manifesting the theory “in a socially recognisable form” (Orlikowski and Iacono, 2001). This act of inscribing, however, results in only the initial design of the theory-ingrained artefact. It is then subjected to organisational practice, providing the basis for cycles of intervention, evaluation, and further reshaping (Sein et al. 2011).
Principle 2 is covered within the literature study on the project and organisational components (Chapter 2), and the preliminary design artefact developed revolving around the project and business cases compiled in Chapter 4.
The artefact will be comprised of practical TX software implementation guidelines; developed templates and secondary sources; and referable project samples that are evaluated concurrently as part of the ADR approach. The artefact details for this research study are divided into three categories, which are interdependent on one another in certain aspects. These categories include project case, organisational components, and strategy development components.
Project case components include the following:
i. Project Request/Identification:
An initial project request form was compiled (template attached to Appendix B), which forms part of the preliminary design artefact created by the lead author as action researcher. The following elements are included in the initial template form:
Project – This is to provide a project reference, which this request will potentially support.
Requestor – This is to provide a reference to the project requestor.
Department – This is to provide a reference to the requestor’s department.
Line Manager – This is to provide a reference to the requestor’s line manager.
Project Background – The requestor must give a brief description of the project, to provide a relative idea of the project as a whole.
Support Request – The requestor must give a brief description of the simulation requirement, and potential deliverables that they would like to see.
Priority – The priority from the requestor’s side should be indicated (low/average/high), to provide additional input for project planning.
Lead Time – Similarly, the basic lead-time for a solution should be provided, to identify the viability of requirements and for project planning.
Signatures – The requestor and their line manager are required to sign and approve the form. This is to provide an additional review step, to increase the credibility of the request.
The initial project request template provides editable space, for a requestor to provide basic project and departmental reference information. Space for a brief description of the requested project and support requirement will provide the simulation engineer with an overview of the problem. An indication of the priority and lead-time required from the project requestor’s perspective will potentially provide relevant information for planning purposes. Lastly, a space for the requestor and their line manager provides a formal sign-off for the submitted request.
ii. Project Data Collection:
Similarly, an initial process data input form was compiled (see Appendix C), which forms part of the preliminary design artefact created by the lead author as action researcher.
The developed template was derived following Bangsow (2015)’s VDI implementation guidelines (described in 2.4.1 Project Components). This document is to be used by the process/simulations engineer in an attempt to collect suitable data sets in line with project request requirements.
Project requestors are required to aid in indicating data available as well as relevant references to aid with the data collection process. The required sections are divided into four sections:
Technical, Operational, System Load, and Human Resource data sets.
Technical Data (T) - This is all of the relevant technical data regarding the facility/processes requiring simulations:
1. Factory Structural Data - Includes production process layouts and equipment/flow information.
2. Manufacturing Data - Includes process data and operational information.
3. Material Flow Data - Includes material flow and material handling information.
4. Failure Data - Includes any process/product/equipment failure data.
Operational Data (O) - This is all of the relevant operational data including shift schedules and production strategies:
5. Work Time Organisation - Includes shift schedules and requirements.
6. Resource Allocation - Includes worker and equipment requirements.
7. Organisation/Facility Strategy - Includes production and maintenance strategies.
System Load Data (S) - This is all of the relevant product and job data included in the process/facility:
8. Product Data - Includes product specifications and BOMs.
9. Job Data - Includes product and transportation orders, with schedules and volumes.
Human Resource Data (H) - Includes input personnel relevant to project/facility/process, and any other additional information regarding data requirements:
10. Input Contact Personnel - Includes project stakeholders and contacts.
iii. Project Data Processing:
Project data processing is an important part of constructing an accurate and/or acceptable simulation model, depending on requirements. A conformance table was developed to identify the data available from the data collection phase; internal data reviews on the processed data sets, as well as potential inclusions; and data obtained on design reviews on developed simulation models, which also affects data processing in certain cases. Table 3 is an illustration of the developed conformance table:
Table 3: Data conformance table (empty)
Data Step Data
Available
Data Review
Design Reviews
Technical Data
1. Factory Structural Data 2. Manufacturing Data 3. Material Flow Data 4. Failure Data Organisation
Data
5. Working Time Organisation 6. Resource Allocation
7. Organisation/Facility Strategy System Load
Data
8. Product Data 9. Job Data
Resources 10. Input Contact Personnel iv. Project Modelling & Simulation:
The model and simulations referenced are constructed following the preceding steps. These files are stored based on revisions constructed by the simulation engineer as the project progresses.
A revision control log is developed for each project sample, to provide a basic description of the modelled revisions.
v. Project Validation & Verification:
Validation refers to the assurance that the model simulation meets the needs of the identified stakeholders. Verification is the evaluation of whether the simulated model complies with the requirement or imposed conditions. This includes result analysis and result interpretation, together with validation and verification in the form of project stakeholder reviews, and reference production data.
vi. Project Reporting:
On completion of a project or project phase, it is important to document simulated results and project progress. This is to ensure clear communication of deliverables and recommendations to act as an effective decision support tool. Summarised project portfolio samples were compiled for all the project samples, to provide a quick reference per project.
The organisational components are relevant to the individual project cases, and strategy development as a whole. The lead author acting as participant-observer logged all the applicable organisational components. The components addressed include the following:
Resource capacity
Software licensing
Training
Feasibility studies
Integration (company and software)
Strategy phasing
The lead author acting as participant-observer also logged the overall strategy development.