4 ms·

Whilst I don’t have a ton of experience in logistics, I have helped executives in other industries map out transition strategies. For the software in question,

Whilst I don’t have a ton of experience in logistics, I have helped executives in other industries map out transition strategies. For the software in question, a few considerations come to mind: - how critical is the software to your company’s competitive advantage? - how big is the vendor team supporting the software? - how much revenue/customers does the vendor currently support? - how much of the software is entirely custom developed vs modules built on top of other platforms? - where does the software reside (on-prem/in-house acct vs mix vs vendor)? Without knowing too much detail about the situation, if it’s an application that is easily testable and verifiable (I.e. perform an action results in observable actions), then it’s much easier to rewrite than an application with background functions and procedures so some level of due diligence or discussion with the vendor maybe useful. Other alternative solutions that may make sense if software is critical: - joint venture with vendor - code acquisition + in-house team - code/team acquisition - short feasibility project to determine migration strategy I’ve worked fairly extensively in transition/acquisition projects so happy to share more if there’s anything specific you’re interested in knowing.

cjblomqvist 2y ago
Lots of good comments in this thread, but I think this is a critical one. It seems you've (OP) almost already decided, but you're unsure about details such as how to retain software developers. Before you go into such details you need to be sure you want to make this move. This must be a strategic move, meaning a long term move where you're sure you're gaining a strategic competitive advantage through this being a core competence (in the academic/theoretical strategic sense). There are very few quick fixes in IT. Most projects are grossly underestimated - in particularly if you lack the competence in-house today (easily 10-100x). At it's core, it should be a decision that is not only about control over the software, it's about bringing the knowledge about the processes and technical complexities of doing your business in-house. You might think you know all about it, but most likely you don't (otherwise most IT projects wouldn't fail). The big cost in IT is specifying exactly how things should work (that's basically what coding is all about). If you're not a developer (and even most developers underestimate/don't fully understand this) it's highly likely you underestimate this part of it (otherwise it would be easy for you to code it yourself - again, how to code is not a big deal, it's specifying exactly how it should work). Software development is a lot about managing and documenting processes, aka knowledge, about your business. Otherwise I agree with lots of other comments. Make sure you and the rest of the business is sure and have enough budget/resources allocated for a long time forward. Bring in a CTO/leader with the experience/skills of doing something like this. Make sure that person has the mandate to do what's needed (hiring, culture, etc). Could be a good idea to do it step by step to test out (again, a good mindset is to see this as an investment in learning about how to do your business, using IT/automation). A hybrid approach could work (take over existing code, use another platform/ERP/system as a base) - all depends on the specifics of your business, how custom your business and processes really are, how core to your business they are, etc. Good luck!
alex_c 2y ago
This comment lists most of the questions I would ask. Couldn't agree more. Only advice I would add for the OP: Check if your contract with the vendor includes any business continuity clauses. What happens to their solution, their code, and your data if they go out of business or get acquired (by someone else)? One relatively common option is to have them put their code in escrow, and get access to it if certain events happen. You can probably negotiate this into your contract if you have enough leverage. If their software is critical to your business, and you feel they are stagnant and underfunded, there may be some risk here you can address today - check with your lawyers. (also, just noticed the username I'm replying to... hi Teren!)
- ensemblehq 2y ago
  Hey Alex! Indeed - good point to ensure business continuity. There should also be a transition period to ensure OP, you’re getting support (like 6 months of service) in addition to code that allows you to address the issue if the vendor does disappear.

cjblomqvist 2y ago

Lots of good comments in this thread, but I think this is a critical one. It seems you've (OP) almost already decided, but you're unsure about details such as how to retain software developers. Before you go into such details you need to be sure you want to make this move. This must be a strategic move, meaning a long term move where you're sure you're gaining a strategic competitive advantage through this being a core competence (in the academic/theoretical strategic sense). There are very few quick fixes in IT. Most projects are grossly underestimated - in particularly if you lack the competence in-house today (easily 10-100x). At it's core, it should be a decision that is not only about control over the software, it's about bringing the knowledge about the processes and technical complexities of doing your business in-house. You might think you know all about it, but most likely you don't (otherwise most IT projects wouldn't fail). The big cost in IT is specifying exactly how things should work (that's basically what coding is all about). If you're not a developer (and even most developers underestimate/don't fully understand this) it's highly likely you underestimate this part of it (otherwise it would be easy for you to code it yourself - again, how to code is not a big deal, it's specifying exactly how it should work). Software development is a lot about managing and documenting processes, aka knowledge, about your business. Otherwise I agree with lots of other comments. Make sure you and the rest of the business is sure and have enough budget/resources allocated for a long time forward. Bring in a CTO/leader with the experience/skills of doing something like this. Make sure that person has the mandate to do what's needed (hiring, culture, etc). Could be a good idea to do it step by step to test out (again, a good mindset is to see this as an investment in learning about how to do your business, using IT/automation). A hybrid approach could work (take over existing code, use another platform/ERP/system as a base) - all depends on the specifics of your business, how custom your business and processes really are, how core to your business they are, etc. Good luck!

alex_c 2y ago

This comment lists most of the questions I would ask. Couldn't agree more. Only advice I would add for the OP: Check if your contract with the vendor includes any business continuity clauses. What happens to their solution, their code, and your data if they go out of business or get acquired (by someone else)? One relatively common option is to have them put their code in escrow, and get access to it if certain events happen. You can probably negotiate this into your contract if you have enough leverage. If their software is critical to your business, and you feel they are stagnant and underfunded, there may be some risk here you can address today - check with your lawyers. (also, just noticed the username I'm replying to... hi Teren!)

ensemblehq 2y ago
Hey Alex! Indeed - good point to ensure business continuity. There should also be a transition period to ensure OP, you’re getting support (like 6 months of service) in addition to code that allows you to address the issue if the vendor does disappear.