Material Requirements Planning (MRP), what is it and how do we perform it optimally?

MRP (material requirements planning) is a technique of assessing dependent demand by using a BOM (bill of material), inventory, expected receipts and a MPS (master production schedule) to determine the material requirements (Heizer & Render, 2009).

When we say “dependent” demand, we are referring to the production of an item that is dependent on certain parts. For example, the production of a motor car is dependent on parts like the engine, wheels, windows, body etc. Heizer and Render (2009) also note that, broadly speaking, “for any item for which a schedule can be established, dependent techniques should be used”.

In a paper by Anderson and Schroeder (1984) points out that MRP can and shouldn’t operate in isolation from the rest of the business (i.e. only in manufacturing). MRP Systems should expand to the other functional areas of a firm and information must flow freely between these areas.

The main functions included by Anderson and Schroeder (1994) include:

1)     Manufacturing
As we have discussed above the main focus behind MRP is on manufacturing. The MRP system is based on the type of product being manufactured, identified by using the Master Production Schedule and Bill of Materials (MPS and BOM). Manufacturing is the core process of developing the products.

2)     Engineering
The engineering function of the firm is where the BOM mentioned above comes from. Anderson and Schroeder use an example of a firm implementing MRP where the BOM from Engineering did not match up with the Manufacturing bills – It is important to make sure all data is correct and this is another reason why all areas of the firm should be involved in the system.

3)     Marketing
Marketing is important to MRP systems because this is where the main demand forecasts are coming from. As mentioned in Anderson and Schroeders (1994) example, marketing “provided the information on firm orders and a forecast for the system”.

4)     Finance
As we know the main point of just about any organisation is to maintain profitability and the MRP system is a tool used to optimise the materials required for production. Finance provides accurate reporting on the performance of the implemented MRP system.

5)     Personnel

At the heart of any organisation is its’ personnel. All personnel should be well educated in and understand the purpose of the MRP system.

Expanding on the last point, the study by Anderson and Schroeder (1994) outlined the implementation of an MRP system across two organisations; one successful and one not. The main reason for the unsuccessful implementation was the “degree of commitment to a system rather than to a concept” (Anderson & Schroeder, 1994).

Educating and training employees to understand the importance and exact steps and procedures involved in the MRP system is very important across the organisation as it affects all functions. 

References

Anderson, J. & Schroeder, R. (1994) ‘Getting Results from your MRP System’, Business Horizons, 27 (3), pp.57-64, ScienceDirect [Online]. DOI 10.1016/0007-6813(84)90028-4 (Accessed: 28 May 2011).

Heizer, J. & Render, B. (2009) Operations Management. Ninth Edition. Prentice Hall: New Jersey.

 

What are the roles of an Operations Manager in addressing the major aspects of quality?

OperationsManager.com (2010) explain the roles of an operations manager to “ensures smooth operation of various processes that contribute to the production of goods and services of an organization”. The following tasks, centred on managing the quality of the service the organisation is providing, are those that are required of an Operations Manager:

  • Ensuring that the tools used to produce goods and/or services are acceptable and are capable of delivering the required quality of service that is acceptable.
  • Liaising with the Quality Assurance personnel to maintain positive feedback on the quality of the produced service or goods from the clients.
  • Assuring that quality tools and equipment are bought/maintained according with the allocated budgets.
  • Managing the support services of the organisation to ensure the most efficient management of support. For example; making sure high quality servers are purchased to store large amounts of confidential data in the most secure manner.
  • Management of any third party relationships the organisation has. Making sure that the agreements with the third parties are sound and that the third parties are performing their duties to the quality expected, as well as keeping to the required procedure standards of the organisation to maintain the highest quality possible.

The Open University (n.d.) explains that “decision making is a central role of all operations managers”. The decisions that the operations manager are involved in are in the design, management and improvement of the operations of the organisation; all of these are directly related to the quality of the service or goods that the organisation provide. If the ops manager makes a poor decision on improving services – the quality that was attained prior to improvements could fall and potentially drive away potential and existing customers, the same goes for the design of a new product/service. If the management of operations are lacking then this could also result in poor service delivery (lower quality).

Heizer & Render (2009) explain the importance of forecasting by the use of forecasting metrics. An operations manager may use the forecasting tools to predict future patterns in service delivery requirements by using trend projections based on historical data (Heizer & Render, 2009). With these forecasting models the operations manager can pre-empt quiet or busy periods (for example: shopping spikes during Christmas holidays) thus ensuring the required resources are available to cope with the demand or lack thereof while maintaining a profitable operation.  Heizer & Render (2009) also point out that these forecast methodologies are not perfect and should always be monitored and maintained according with “new” historical data.

In summary and conclusion the roles that an operations manager play in addressing the major aspects of quality is comparable with their job function as a whole; they must ensure processes are kept to the required quality for the organisation while maintaining a profitable and manageable operation.

References

Heizer, J. & Render, B. (2009) Operations Management. Ninth Edition. Prentice Hall: New Jersey.

OperationsManager.com (2010) Operations Manager job description: daily tasks, roles, duties and responsibilities [Online]. Available from: http://www.operationsmanager.com/operations-manager-roles-in-the-company/jobs-roles-duties-and-responsibilities/ (Accessed: 21 May 2011).

The Open University (n.d.) The role of the operations manager [Online]. Available from: http://openlearn.open.ac.uk/mod/oucontent/view.php?id=397333&section=2.3 (Accessed: 21 May 2011).

Software Architects – How will this position change in 10 years?

The question at hand I would like to discuss is, how do I think the position of a Software Architect will change in the next 10 years?

In ten years’ time I believe this position will definitely still exist and I am quite sure there will be many more holding this position than today.

In the future I have a strong belief that software architects will have to structure their software planning based more heavily on developing middleware and collaborative systems (“cloud computing”) than developing brand new systems. In an article by Pokharel and Park (2009) it is mentioned that “Cloud computing is the future generation of computing”. Today we see a number of large applications becoming increasingly popular and in my personal experience developing new software that “talks to” external systems is becoming more and more popular. In one project I have worked on it was a potential deal-breaker if our software was unable to talk to SAP.

 

In a paper by Medvidovic (2002), it is stated that “While architecture is an early model of a system that highlights the system’s critical conceptual properties using high-level abstractions, middleware enables that system’s realization and ensures the proper composition and interaction of the implemented components” followed by “The relationship between the two areas and their respective shortcomings suggest the possibility of coupling architecture modelling and analysis approaches with middleware technologies in order to get ‘the best of both worlds’ “. I believe this is a substantial statement supporting my beliefs.

 

The current focus of software architecture, in my personal experience, does seem to be aimed at the creation of vastly “stand-alone” components with the only real reliability being on the operating system the software will be running on. The large, successful developments of today will be the focus of the middleware of tomorrow.

 

I believe that in 10 years’ time the training required to perform the duties of a Software Architect will be the same as today but will include new training based on existing systems and how to make them work together efficiently via API’s/middleware as well as the requirement for more experience in developing these modules.

 

As far as automation goes, I believe the current movement towards the use of programming frameworks will only increase, while low level programming will be far less of a requirement when planning the development of a system. Using components of a framework (one can think of a framework as a library of “functions” to perform common tasks so that the programmer does not need to do it themselves) will enable a much larger focus on the bigger picture and allow for more complex systems to be developed.

 

References

Medvidovic, N. (2002) ‘On the role of middleware in architecture-based software development’ SEKE, 27, pp.299-306, ACM [Online]. Available from http://doi.acm.org/10.1145/568760.568814 (Accessed: 12 September 2010).

Pokharel, M and Park, J. (2009) ‘Cloud computing: future solution for e-governance’ ACM International Conference Proceeding Series, 322, pp.409-410, ACM [Online]. Available from http://doi.acm.org/10.1145/1693042.1693134 (Accessed: 12 September 2010).

 

 

In ten years’ time I believe this position will definitely still exist and I am quite sure there will be many more holding this position than today.

In the future I have a strong belief that software architects will have to structure their software planning based more heavily on developing middleware and collaborative systems (“cloud computing”) than developing brand new systems. In an article by Pokharel and Park (2009) it is mentioned that “Cloud computing is the future generation of computing”. Today we see a number of large applications becoming increasingly popular and in my personal experience developing new software that “talks to” external systems is becoming more and more popular. In one project I have worked on it was a potential deal-breaker if our software was unable to talk to SAP.

In a paper by Medvidovic (2002), it is stated that “While architecture is an early model of

a system that highlights the system’s critical conceptual properties using high-level abstractions, middleware enables that system’s realization and ensures the proper composition and interaction of

the implemented components” followed by “The relationship between the two areas and their respective shortcomings suggest the possibility of coupling architecture modelling and analysis approaches with middleware technologies in order to get ‘the best of both worlds’ “. I believe this is a substantial statement supporting my beliefs.

 

The current focus of software architecture, in my personal experience, does seem to be aimed at the creation of vastly “stand-alone” components with the only real reliability being on the operating system the software will be running on. The large, successful developments of today will be the focus of the middleware of tomorrow.

 

I believe that in 10 years’ time the training required to perform the duties of a Software Architect will be the same as today but will include new training based on existing systems and how to make them work together efficiently via API’s/middleware as well as the requirement for more experience in developing these modules.

 

As far as automation goes, I believe the current movement towards the use of programming frameworks will only increase, while low level programming will be far less of a requirement when planning the development of a system. Using components of a framework (one can think of a framework as a library of “functions” to perform common tasks so that the programmer does not need to do it themselves) will enable a much larger focus on the bigger picture and allow for more complex systems to be developed.

 

Bibliography

Medvidovic, N. (2002) ‘On the role of middleware in architecture-based software development’ SEKE, 27, pp.299-306, ACM [Online]. Available from http://doi.acm.org/10.1145/568760.568814 (Accessed: 12 September 2010).

Pokharel, M and Park, J. (2009) ‘Cloud computing: future solution for e-governance’ ACM International Conference Proceeding Series, 322, pp.409-410, ACM [Online]. Available from http://doi.acm.org/10.1145/1693042.1693134 (Accessed: 12 September 2010).