One general answer and one specific answer. (Numbering is my own and doesn’t correspond to your questions.)
When implementing a new system that will be used by a variety of people in your org, it’s important to make this as easy as possible for them. As Martin said, if you end up with one person who doesn’t want to use the system, this will greatly increase your work. When you’re choosing a new tool or system for people, you should assume that all of your new users don’t care about it, and that any time they have to spend learning the new system will be time they’d rather spend doing something else. To that end:
Don’t just ask people to read the software’s own published user guide. Even if it’s really great and you couldn’t imagine making anything better! People don’t want to click on links, they don’t want to go somewhere else and see new branding, they just want you to tell them what to do.
Do write specific instructions, in an email, as clearly and concisely as possible. Even if those instructions mirror the software’s user guide, it’s likely you can make them more concise because your instructions are for your org’s specific use case.
Do offer to help anyone who struggles with the new system. It’s unlikely anyone will take you up on this offer, but I think it makes people feel like you know they don’t want to do this thing you’re asking them to do.
Be ready for people to keep trying to use the old system. Keep trying to shepherd them into the new system. Don’t give up, don’t resign yourself to the two-system world. People will fail to see your first email, but happily respond to your follow-up. Seize opportunities to walk someone through a concrete example: Maybe they didn’t set up their Expensify account the first time, but now they’re asking for reimbursement, so you can (nicely, graciously) force them to use Expensify to get it.
BERI uses QuickBooks Online (QBO) as our accounting software. It works well enough, but has a lot of quirks that make certain things much more difficult and confusing than they have to be. Consequently, I’m (slowly, hesitantly) looking into other options, Aplos in particular. Obviously I’ll want to try out all of our normal transactions and reports in Aplos before transitioning. But even if all of that works out really well, one thing I’m very worried about is loss of audit trail: QBO keeps a record of every change to every transaction, including the time, date, and user. I’ve only used this occasionally, but when I have it’s been a lifesaver. I’m not sure how I’ll get around this if we start using Aplos, but it’s definitely something I’ll be keeping in mind. This concern would apply to any important piece of software that stores a complex history of interactions.
One general answer and one specific answer. (Numbering is my own and doesn’t correspond to your questions.)
When implementing a new system that will be used by a variety of people in your org, it’s important to make this as easy as possible for them. As Martin said, if you end up with one person who doesn’t want to use the system, this will greatly increase your work. When you’re choosing a new tool or system for people, you should assume that all of your new users don’t care about it, and that any time they have to spend learning the new system will be time they’d rather spend doing something else. To that end:
Don’t just ask people to read the software’s own published user guide. Even if it’s really great and you couldn’t imagine making anything better! People don’t want to click on links, they don’t want to go somewhere else and see new branding, they just want you to tell them what to do.
Do write specific instructions, in an email, as clearly and concisely as possible. Even if those instructions mirror the software’s user guide, it’s likely you can make them more concise because your instructions are for your org’s specific use case.
Do offer to help anyone who struggles with the new system. It’s unlikely anyone will take you up on this offer, but I think it makes people feel like you know they don’t want to do this thing you’re asking them to do.
Be ready for people to keep trying to use the old system. Keep trying to shepherd them into the new system. Don’t give up, don’t resign yourself to the two-system world. People will fail to see your first email, but happily respond to your follow-up. Seize opportunities to walk someone through a concrete example: Maybe they didn’t set up their Expensify account the first time, but now they’re asking for reimbursement, so you can (nicely, graciously) force them to use Expensify to get it.
BERI uses QuickBooks Online (QBO) as our accounting software. It works well enough, but has a lot of quirks that make certain things much more difficult and confusing than they have to be. Consequently, I’m (slowly, hesitantly) looking into other options, Aplos in particular. Obviously I’ll want to try out all of our normal transactions and reports in Aplos before transitioning. But even if all of that works out really well, one thing I’m very worried about is loss of audit trail: QBO keeps a record of every change to every transaction, including the time, date, and user. I’ve only used this occasionally, but when I have it’s been a lifesaver. I’m not sure how I’ll get around this if we start using Aplos, but it’s definitely something I’ll be keeping in mind. This concern would apply to any important piece of software that stores a complex history of interactions.