I worked in the Financial Systems Analyst role in the IT department at Methanex. More specifically, I worked with Oracle Solutions, a team within the IT department. In May 2021, Methanex launched a new ERP system, used to manage a wide range of data from throughout the company’s finance activities, to derive insights regarding operational excellence, and to construct reports used to support the firm’s finance activities. Although I did not work with the ERP extensively, my role was to develop the boundary systems surrounding this large software implementation. This included the queue management system, called ManageEngine. This system is crucial in my team’s efforts to provide support to the firm’s employees as they use the ERP to complete their daily tasks, to fix system bugs and to deliver system enhancements, all in a timely and efficient manner.
A large portion of my time with Methanex was spent working on a boundary system implementation of ManageEngine’s robust lifecycle, digital asset management and reporting features. Thus, much of the learning experiences I had throughout my work experience stemmed from this project. At the time I joined the team, we were using a patchwork of 2 different systems – ManageEngine and Azure DevOps – to manage support and bug fix/enhancement tickets, respectively. The project’s overall goals were to 1) migrate queue management into a single system, 2) generate a consolidated view of development timelines for bug fixes/enhancements, and 3) develop valuable reports through the provider’s extensive integrated reporting features. As I was involved from the very beginning of the project, I learned the full scope of work behind a major business process change.
The project started with the early development stages. At this point, a business analyst – who over time became my mentor – and I worked exclusively from a theoretical perspective. This means that while we did have access to a ManageEngine test space, we worked purely on “paper” (Excel) to develop a ticket lifecycle schema, with conditional process flows, process tasks, and inputted data requirements. Once we had this reviewed by management several times, we were then given the greenlight to configure the full lifecycle in the provider’s test space. The configuration phase taught me valuable lessons about implementation, such as the importance of offline documentation, the age-old IT adage “configure, don’t customize”, and much more. Beyond first principles, I also learned how to configure a ticket lifecycle within an out-of-the-box software. This included simple elements such as adding process states, tasks, and form fields to the more complex, such as defining the conditional logic elements that allow the lifecycle to flow in different directions based on user inputs. The last phase before go-live was testing and training. This included validating every detail of the configuration through tests, as well as developing slideshows, demos and training documentation for system users. I was entrusted with developing all these elements for an entire branch of the lifecycle. Though it was difficult work, it was also very rewarding to know that I had been directly responsible for a major process change that will continue to impact the team in positive ways long after I’ve left.
I strongly believe that what I have learned through working on this project has been extremely valuable for my career progression. As I plan to go into product management, I will need to be able to balance the technical aspects of that job with the people aspects. This project gave me the opportunity to think critically within a technical mindset, but also to justify my decisions to stakeholders, defend my viewpoints and present process changes in such a way that adoption is made as simple as possible. I am sure that both sides of this coin will be very valuable to me in the future.