I find accounting boring. I can do it. And I have studied it various times throughout my life. And somewhat ironically, I have spent a fair amount of my life writing software that performs accounting.
At the end of my senior year of high school, I took an in-class Accounting final exam. When the test started, I first programmed my micro-computer from scratch (it would be dishonest to write one in advance) in the BASIC computer language program to properly store debits and credits into T-accounts. Then I used that program to process the rest of the exam questions. If I remember correctly, I was the first to turn in the final exam, and I got a perfect score!
For me the passion comes, and flows, when I am engaged in a creative endeavor. And strangely, I sometimes relax by writing software code. I love software!
Recently I developed a custom CRM program to help me better communicate with hundreds of young single adults. I also wrote a custom ERP system for Jigabot. I wrote both of these systems using the latest Microsoft frameworks, security, and cloud storage, so I had to learn new things (see post on learning here.)
By the way, one of the reasons that I wrote a custom ERP system is that no ERP system–unless custom written–comfortably works for any organization. (I spent 5 years developing an ERP system, and learned this first-hand.)
Here’s why: for an ERP Vendor to succeed, their software has to work for “all” companies within a selected industry or niche. And that means Vendors tend to add (even compete based upon adding) more and more features. But most companies don’t use “all” features–they use a subset based upon their own work processes and reporting needs. And so all of these extra features become complexities for many organizations. And thus mature software tends to becomes “overly complex” over time. Or more fitting for larger, more complex organizations.
The other problem is this: when Vendors add a pile of features, they still don’t manage to include every feature that a particular organization might need. Or implement them in a way that works for every organization. Again, that’s because each organization has different processes and policies, and hence different software requirements. And thus some software is feature-rich but still not “fully functional.”
Many companies simply choose to change their work processes in order to conform to software solutions. Which can create additional challenges. (Consider that organizations use economic theory such as Porter’s Competitive Advantage, or McKinsey’s 7-S Model, to compete in the marketplace based upon unique capabilities and processes. So by definition organizations must have unique systems, not completely standardized ones.)
So given these two problems of needing to balance software simplicity with fully supporting unique processes, it may well be that the only software that fully works for an organization is either (1) a custom ERP software creation, or else (2) a customizable ERP software system that allows for simplifications of the user interfaces and implementations of unique process flows.
At BYU I studied two accounting classes in my MBA program: operational and financial. Over the course of the next 5 years, and while I was getting first-hand experience as a business consultant, the whole world seemed to be discovering the value of ERP systems.
So during the next 5 years, I turned my full-time attention to developing and marketing an ERP system to a segmented niche, gaining first-hand experience and insight.