Learning Management Platform Transformation & Process Automation
A transformation project focused on replacing a legacy Learning Management System with a more structured digital solution, while rethinking existing processes, introducing new capabilities, and increasing automation across the platform.
My role covered a broad part of the Business Analysis lifecycle, from understanding and documenting the current state, to defining the target state, structuring business and functional requirements, translating them into a detailed prototype, and supporting adoption through documentation and knowledge sharing.
The Challenge
Modernizing the system without carrying its old limitations forward.
Replacing an existing system is rarely just a matter of rebuilding the same functionality in a newer interface.
The project required understanding how the current LMS actually worked, identifying gaps and improvement opportunities, defining how the future processes should operate, and making sure the new solution did not simply carry old limitations into a new platform.
The challenge was therefore to create a clear bridge between what existed, what the business needed, and what should ultimately be built.
My Contribution
From understanding the current system to defining the future one.
Built the As-Is Baseline
I analyzed the legacy LMS and documented its existing processes to establish a reliable picture of how the system operated before proposing changes.
The As-Is analysis helped surface gaps, manual steps, and areas where processes could be simplified or improved.
Rather than starting from assumptions about the future solution, this created a grounded baseline for the transformation.
Defined the To-Be State
Based on the current-state analysis and business needs, I documented the proposed future state of the platform.
The To-Be analysis described how processes should work after improvement and automation, helping distinguish between what needed to be preserved, redesigned, introduced, or removed.
This became an important bridge between process analysis and detailed requirements.
Structured Requirements from Business Need to System Behavior
I authored the Business Requirements Document (BRD) to capture the high-level business needs and direction of the solution.
I then developed the Functional Requirements Document (FRD) to translate those needs into more detailed system behavior and functionality.
This created a clearer progression and provided a structured reference for implementation.
- Business Need
- Process
- Requirement
- Expected System Behavior
Made the Requirements Visible Through a Five-Role Prototype
Alongside the FRD, I designed a detailed prototype covering the platform experience across five distinct user roles.
The prototype helped connect written requirements with actual user journeys, screens, actions, and system states.
Instead of reviewing requirements only through documents, the team could see how they would translate into a working experience and identify inconsistencies or missing details earlier.
Embedded Compliance into the Design
Applied relevant Digital Government Authority platform-code requirements across the system prototypes.
This meant considering compliance as part of the solution design rather than treating it as a separate check at the end of the project.
The requirements therefore influenced how the proposed interfaces and interactions were represented from the prototype stage.
Shared the System Beyond the Project Team
Delivered system overview sessions to internal teams across different departments to explain the platform, its structure, and key processes.
These sessions helped create a broader shared understanding of the solution beyond the immediate analysis and development context.
Turned the Final Solution into Role-Based Guidance
Prepared user guides tailored to the different roles within the system.
Rather than creating one generic manual, the documentation focused on what each user needed to understand and do, using structured instructions and annotated interface visuals as a practical reference for adoption.
Key Deliverables
A connected set of artifacts, not separate documents.
As-Is Analysis
Documented the legacy environment, current processes, gaps, and improvement opportunities.
To-Be Analysis
Defined how the target processes should operate after redesign and automation.
Business Requirements Document
Captured high-level business needs and the intended direction of the platform.
Functional Requirements Document
Translated business needs into detailed functionality and expected system behavior.
Five-Role Interactive Prototype
Connected requirements to user journeys, interfaces, interactions, and system states.
Compliance-Aware Prototype
Reflected relevant Digital Government Authority platform-code requirements in the proposed experience.
Role-Based User Guides
Created practical references tailored to how different roles interact with the system.
Skills in Practice
What this transformation required in practice.
- As-Is Analysis
- To-Be Analysis
- Gap Analysis
- Requirements Elicitation
- Requirements Analysis
- Requirements Engineering
- Process Improvement
- Process Automation
- Business Rules
- Interactive Prototyping
- Compliance Analysis
- User Documentation
- Knowledge Sharing
Takeaway
Transformation starts with understanding what should change, not simply what should be rebuilt.
This project reinforced for me the importance of maintaining a clear line from the current problem to the proposed solution.
An As-Is document, a To-Be model, a BRD, an FRD, and a prototype should not be isolated deliverables. Together, they should tell the same story at different levels of detail.
When that connection is maintained, requirements become easier to trace, discussions become clearer, and the prototype becomes more than a visual reference. It becomes another way to validate the analysis before implementation.