ERP – Enterprise Resource Planning – the offspring of MRP and MRP II – the logical extension of the MRP II extention from MRP.
MRP – Materials Requires Planning. Focused on improving the quality, quantity and costs of materials from the supply chain through production into finished goods – or getting merchandise purchased to available as stock for sale, if not manufacturing or service industry.
MRP II – Manufacturing Requirements Planning – expanded the notion and tool-set beyond simply the materials needed for a process or the many processes that manufacturing, into all requirements.
ERP – Enterprise Requirements Planning – expanded the notion and tool-set beyond simply everything required for manufacturing into all requirements, for all Departments, Functions, Divisions, Etc..
Part of ERP Systems are People Sub-Systems – and the data to facilitate those.
In my perfect world those People data systems would be organized to align to the logical set of these: DEPARTMENTAL Areas of Performance (AoPs).
The intent of that model is to accommodate a Department becoming Process-centric.
This should enable them to plan and manage both the Processes that they own as a Department – that are unique to them, and also the Processes that they don’t own but that they support none-the-less.
The model also enables the use/re-use of common systems and processes, “as is” or “after modification” (if/as approved), such as those processes that might be used in Payroll, or Purchasing, or Sales to verify someone’s identity.
Many or few departments could embrace this common model and begin to uncover all of their shared needs. For enablers including but beyond knowledge and skills.
An Architectural approach to content for an Enterprise Learning Context would reflect the people’s’ job Tasks and the Enterprise’s Processes, and the common enabling awareness, knowledge and skills shared by a few, many or everyone. And may use T&D/L&D as one of many channels to send coordinated messages to improve awareness and knowledge and assist in skills development by local managers.
An Architecture would organize Content for Context.
An architectural approach to a modular curriculum would guide investments in targeted content – not just all content.
Managing what “is to be left to informal means” – and then insuring access and competence is developed to enable informal learning means is key.
Managing what is attended to by formal learning means and what is to be left to informal means – still needs to be enabled with policies, practices, tools, etc. that enable those informal means – which may look very different one department to another, and one cross-functional team to another.
A common view would tag the manufacturer’s user guide instructions for tools used and link it to all of the Processes where it is used.
A Data Architecture is required that accounts for many other “non-Learning & Development” organizations.
You can make this happen.
You can serve your needs to enable the Processes of the Enterprise more Effectively and Efficiently – by enabling unique Processes and standard Processes to co-exist.
The Micro-level and the Mid-level and the Macro-level data-sets need to be rooted at some “thing of value.” That’s why my analysis and design and development efforts are rooted at improvement of the Process, and Processes upstream that themselves enable the Targeted Process or Process-set.
Then there are People Structures, formal and informal that need active, visible roles and responsibilities – that transcend the department – that reach back into the supply chain and forward into the customers’ customers’ needs and your Stakeholders’ Stakeholders needs.
But that’s another Blog Post.
Call or email if you’d like assistance.
We come with references.
Some are here at LinkedIn.
I also do staff development in my methods – and have been doing so since 1984.
# # #