Accuity Order Management System 

…with Accounting functions

The Project

Accuity was planning to separate from its parent company. All order management functions—from reports that drive fulfillment, to label creations, to revenue recognition, to Accounting reports—were held in custom-built software whose developers had long ago left, and whose source code was not available for review. We needed to reverse-engineer the entire process, building a new OMS into Salesforce.com as a platform.

My Role

As Corporate Solutions Manager, I ran the entire project, serving as lead architect and de facto project manager. I leading a small team of one developer and one analyst, doing extensive user and business research, defining and building solutions, writing workflows and reports, defining data mapping, and doing extensive data analysis.

Research

Accounting & Finance

I had extensive meetings with Accounting to understand all of the reports they needed and what they used them for. In the process, I had to learn the principles of accrual-based accounting, which then drove my understanding of what the OMS needed to do..

Fulfillment

We had fulfillment specialists who ran processes and exported reports, and we had the warehouse manager who sent out our books, and we had the technical fulfillment team, who sent out all of our data files. I met with all of them to understand their processes and needs so that they could continue to do their job with the new tools we were building.

We were building business-critical processes and needed to get them right.

Build

System limitations

Because we were building in Salesforce.com, we were very limited in what we could build for an interface. We could control the workflow and the organization of information, which we documented and tested with users and stakeholders.

My analyst and I divided the work up; she handled Sales processes, and I handled Fulfillment and Accounting.

The release

We released in the fall, and within a month it was announced that we’d been acquired by a new company. Our CTO told me that the imminent release of the OMS was a factor in the acquisition going through.

Learnings

Agile vs Waterfall

This was a large project that could not be released until all features were built, and I thought that meant we had to run it as a waterfall project. At the end of the project, I vowed never to do that again. Even if you cannot fully release a project until the end, you can still run the project iteratively.

Appropriate tools

Salesforce.com is a very powerful tool, but it was not the right tool for the job. It had too many limitations at that time for this application.

Team size

The project was a monster—an enormous amount of high-stakes work completed by a tiny team. One more person would have made an enormous difference; if I had it to do again I would have advocated for a dedicated hire or contractor.