You’re not special…
I read a book a while back called Stumbling on Happiness, by Daniel Gilbert. It’s sort of a classic self-help book about unlocking the keys to happiness, but it takes a bit of a more scientific approach. One particular chapter really stuck out to me. One of the key differences between happy people and unhappy people is that happy people seem to think they have more in common with other people than differences. Unhappy people the inverse. He uses an example where he gathers participants in a room and shares some statistics with them. 45% of married people will get divorced. 60% of people will struggle with weight loss and so on. Later he surveys the individuals on the likelihood of they themselves getting divorced or struggling with weightloss. Then charted their responses against their self ranked happiness score. Correlation: Eureka!
You might ask what this has to do with Sage Intacct implementations. But it never fails… we kickoff an implementation with a client, and I hear these words: “we’re special”. I hate to break it to you but after seeing under the hood of 100s of client Sage Intacct instances across a variety of industries, my answer is always the same: maybe, but you should really try your best not to be.
I get it, Controllers… from where you sit you inherited a set of books and are doing your best to hold the whole thing together. You learn the “special” and remain dedicated to preserving it lest something break. But the reality is that it’s this “special” that leads to lack of scalability, errors and long-term failures. You implement complex customizations in an attempt to automate the special. Then an update causes an unexpected failure. You spend so much time and money trying to fix it. I would like to propose a better application of your limited resources. Step out of the day to day and ask yourself why you’re doing it this way to begin with.
I try to get the client to ask this uncomfortable question and invariably get the same response: because we always have. This is a light bulb moment. People often forget that systems and reporting requirements evolve. Sometimes we invoice things a certain way and then one customer brings in a wild requirement and we accommodate it. Then another. And another. Before you know it the accounting shop is devoid of any system. They’re relying on sticky notes to process invoices.
I used to do an experiment with my stakeholders who would request delivery of complex reports into their inbox sometimes daily. I’d create it, schedule it, let it run for a couple of months and then turn it off. 90% of these reports would go unnoticed, unread meaning: unactioned! And here we thought these were mission critical!
Sometimes the key to long term success is focusing on what we all have in common and trying to apply time to the particular things that make us different and try to get rid of them. Have a vendor that requires you to cc 15 people on every payment? Pick up the phone and ask them why.
Need to export your GL to create highly customized reports for your various funders? Re-work you CoA and dimensions such that it accommodates 80% of them.
Having an issue matching payments from customers with invoices issued? Use standard functionality to create matching conditions and build standard systems of how you record receipts.
Re-inventing the wheel is costly and error prone. As I was writing this, I received a text message from an old colleague:
My reply:
