Friday, June 20, 2014

Does this App Belong in my Ecosystem?

Yes? 

No?

Maybe?

All of the above.
But how do we know? We encounter too many scenarios with our clients where they are looking for a cut and dry response that we cannot provide for them. Just like nearly every other question when it comes to apps, accounting and taxation - it depends.

What does the app do?
We all know the phrase - there's an app for that! But what, exactly, is that? Is your app a time tracker, a payroll add-on with time tracking, a POS, a POS with time tracking, an inventory manager, an inventory manger with POS, an inventory manager with POS and time tracking, blah blah blah? There are a million different things that your app could be capable of, and the first thing that you need to know is exactly what the capabilities and limitations are. Once you know what your app can and cannot do, you can decide on the next question.

What is the app's role in the Ecosystem?
Many of us have taken the term 'Appify' and ran with it. Some of us ran the course, and some have gone off-roading... The biggest problem I see are app stacks instead of app systems (no relation to AppStack mobile site builder). Piling one app on top of another on top of another and so one just creates a huge mess. Many times an app will be integrated and later you find out that it is missing a feature, so you get another add on to fill that need and you end up with a million apps that no one can keep track of. There are plenty of awesome ecosystems that involve a strand of apps working together, and knowing each role and result in depth will help you decide which ones qualify as a system and which ones just make a crap pile. 

Stack vs. System
When we are designing an ecosystem for a client, we look at multiple options for each process that requires a solution. A good saying here would be 'if you fail to plan you are planning to fail'. Let's compare two examples of a landscaping company:

A: Implements When I Work with GPS for time, Zen Payroll for processing, and SalesForce for appointments while using QBO for back-end accounting. 


When I Work > Zen Payroll > QB Online < Sales Force

B: Implements Jobber for time/appointments/field management and QBO with payroll for back-end accounting.


Jobber > < QBO/QBOP

(If you are not sure which of these is a stack and which is a system, please send me a private email for a consulting session...)

The moral of the story is that both of these examples fill the need, but they are not created equally. You need to know your end goal and choose the apps that work together effectively to make the most streamlined system.

How much control do you need/want over the data?
I have overheard waaaay to much whining that all app data needs to 'sync seamlessly into QuickBooks' to be perfect. I say NO WAY!!! One of the BIGGEST benefits I see to appification is that you can choose an app based on its ability to feed information into your back-end accounting system. We all have 'that client' that no matter how much we train them, they will always mess up their books. I love that I have platform options so that I can put 'that guy' on the POS that allows me to look at their beautiful reports and post them as journal entries (rather than automatically sending every erroneous transaction into QB for me to clean out). I believe that the best apps are those that give you options on how you retrieve your data.

What does your data look like once it is in the back-end system?
My answer to this: who cares? As long as it is accurate and not redundant, I prefer ONE posting from the app to summarize the information. Most people ask my why I would not want every transaction to come through... Well, if I wanted every transaction spelled out in QuickBooks then why the heck did I buy the app??? Of course the expectations for import will vary depending the goal you are trying to achieve, and if you have completed the proper ecosystem engineering process then you should be able to assess the part quite simply. Just remember that you are looking for a streamlined system, not a redundant stack.


Would you be interested in a course on this subject? 
Tell us on Twitter @PetersonBizSvcs

No comments:

Post a Comment