Support for the Standard Framework Version 3

The following sections describe in greater detail why the framework evolved as it did, giving the reasons behind the additions made.

Problem Structuring and Design

The two phases, Problem Structuring II and Design, were omitted from the first version of the standard framework. As a result, when the standard was applied to the BioSynT case study, the project took far longer than expected and required a complete rebuild because it simply did not meet the requirement specifications and

failed to fully cover the given scope (albeit a rather unclear scope). This is shown by the timeline in Figure 3.4.

The first problem was that the model was built too quickly based on too many assumptions where the information required was not available. In fact an initial meeting with the client did not take place until the majority of the model was already in place, having been built based entirely on a process Gantt Chart. The problem faced here regarding the data for modelling is not a new one. Sadowski and Grabau (2000) suggest that the problems regarding data are that it can be insufficient or at times excessive such that the modeller has difficulty in identifying the relevant parts and furthermore there can be the danger of misinterpretation of the data especially where the modeller is unfamiliar with the system.

Secondly, many important system elements which greatly affect the scheduling and resource management were omitted such as probe failures, additional rules like storage allowances and wait thresholds on columns. One could argue that these are not added upon initial model construct anyway and only come about after discussions with the client. However this did not happen. Such elements may not be discussed on the first or even second meeting with the client for two reasons, (1) the client is usually unaware of the capabilities of the model and the significance of these elements to its running (2) the modeller is more often than not unfamiliar with the system and therefore does not know the right questions to ask or data to seek.

What these reflections on the initial model construct suggest is that the approach to the process may have been wrong and that greater or, more importantly, ‘better’

communication with the client would have shortened the construct phase and would most likely have negated the need for an entire rebuild. Here is posed a dilemma: a hasty model construct can result in a model largely based on assumptions and not truly representative of the system. But too much time spent on the design and waiting for data can delay construct indefinitely. The solution here is to have a set of standard questions which are common to similar systems. For example perhaps with a biotechnology manufacturing system the questions must always be regarding Cycle Times, Activities, Resources, Rules for resource usage and Labour. This would help in the case of a model where the remit is to look at scheduling. But what about in the case where the model needs to answer the question of flow, taking into consideration utilities availability and flow constraints in the same biotech facility? In which case

information such as Vessel Volume, Flowrates and Utility requirements would be more useful than labour and perhaps resources such as buffers (unless these too share the same utilities). Therefore it is not only the system being modelled which must be considered when asking for the relevant information but also the question being asked or the remit.

Templates

These observations made above were tested during the mAb case study, which as Figure 3.5 shows, took significantly less time than the BioSynT study. This can not only be attributed to the existence of a far more comprehensive problem structuring and design stage but also the existence of the early version templates which aided in the construction process by acting as basic building blocks, reducing the variability in structure and narrowing down the possibilities amongst the myriad of ways to model a particular system element or feature. However, the mAb case also showed that there are shortfalls to the framework. Firstly, although the construction phase was accelerated, the debugging stage took far too long. It can be argued that better model outputs or built in indicators could have helped. Secondly, the degree of customisation later made to each of the template blocks was quite significant, with many features such as lot cycles added to the chromatography columns. Perhaps the templates could be taken a step further by creating different blocks for the different functions such as fermenters and columns. This would subsequently reduce the degree of customisation and thus reduce the construction time, possibly impacting the debugging phase also.

The database template was initially designed and built within Extend, using the SDI link to externalise it to Excel for user input. However a major flaw with the SDI tool is that in order for Extend to be able to read the external database, its structure must follow certain rules, which do not lend themselves to a necessarily user friendly input. In this case, upon review with the end user of the model, it was decided that bypassing the SDI tool would create a far more intuitive database, with structures familiar to the system users. Subsequently the database was externalised, making the Excel end of the data link the front end of the database construct, with all table structures designed to maximise user intuitiveness. The data from this database would then feed into the internal database automatically upon model initialisation,

taking the form required for global reference within the model. Section 3.5.3 will describe this template in far greater detail.

Due to the fact that the templates library very much evolved during the construction of the mAb model, additional template blocks were created to meet requirements of system features as they arose during the project validation meetings. Upon review, it wasseen that many of the blocks could be combined. For example, there were three different blocks, the Makeup, Primary and Secondary activity blocks, which were practically identical in structure but which looked different and had different names.

Combining these would simplify the library significantly.

Conversely, the level of standardisation created by building a single activity block for all system functions is perhaps too great. For example, the single main product handling activity template block was used to build all unit operations from fermentation to chromatography. The difference between the operations was then built in by tailoring the blocks to represent the system elements. It can be rather difficult to strike the correct balance between standardisation and customisation, with general consensus stating a 80/20 rule appropriate. That is, 80% of the functionality is provided by the template and 20% is customised by the modeller to achieve 100%

system representation. However the degree to which these blocks were changed or added to far exceeded 20% in this case and therefore it can be argued that the level of standardisation was too great. For example, perhaps it would be more efficient to create separate blocks for the different unit operations allowing for their different system features to be incorporated into the template rather than later added in.

This increased specificity of each functional block poses a potential problem as it could limit the use of these blocks across different types of biopharmaceutical system. For example, could the library blocks be used to rebuild the fill/finish model? The answer is most likely no, as the level of customised functionality added means that the relevance of each block to a different system will be diminished. In order to be representative, each block would have to be further customised, exceeding the 20% desired customisation threshold, thus making model construct inefficient. Therefore, it is proposed that there be a different library of blocks for the different systems i.e. one for biopharmaceutical manufacturing and one for fill/finish.

This grouping of manufacturing systems is made possible by the commonalities

between the systems, for example the existence of chromatography columns in both the BioSynT case and mAb. Furthermore, the different types of activities found are also common, for example, all biopharmaceutical manufacturing processes will have ancillary activities and buffer/media makeup of some sort. Whether these elements fall within the scope of the model is at the discretion of the modeller however they will be present in the library if needed.