Hacker News Reader

> Consider that the software you're using, buggy and kludgy as it is, isn't the reason your business is making (or failing to make) profits.

You seem to be making that assertion with 0 evidence. I've seen plenty of businesses fall behind because their tech is old and becomes an anchor, and I've seen businesses whose primary competitive advantage is their tech.

In fairness, they aren't making that assertion, they are asking for OP to consider and pressure test that assertion

I've also seen businesses fall behind because they were chasing the latest tech fads even though those did nothing for their business.

I totally agree, but OP's post doesn't seem to be of that type - it's not like he's chasing some nebulous tech buzzword ("Sprinkle in some blockchain!", "Be sure to utilize AI!"), but he has a good idea of the specific pain points, at least in broad strokes.

At the very least, similar to other comments about hiring a small group of senior freelancers, I think to start it makes sense to find a very good contract product manager who can map out, very explicitly, exactly what the pain points are and what a software solution would look like to fix them, stack ranked by "biggest bang for the buck" (i.e. most positive impact to revenue or reduced cost, divided by rough estimate of size of the fix). At that point the total investment would be very low, and then they can make the call of whether the risk of doing something not using COTS tools makes sense.

I agree with your general thoughts. I've been designing+developing+managing ERP/SupplyChain/WMS/Shipping systems+projects for a loooong time and the chance that a person with no background in it will build the right small team to pull this off correctly on the budget any small to medium size company has, while running their business, is generally low.

> You might get around the drudge work of automating some of the toil work by hiring freelancers/consultants.

Finding the right people with the right experience and right aptitude is tough (for any role). Whether internal or external resources, my rule of thumb is that maybe 20% are fully capable, 50% are reasonably valuable to some degree, 20% have limited value and 10% are just not in the right role at all.

Whether trying to find a PM or solution architect or technical lead or dev, these same percentages apply. You have to really have experience to have a reasonable shot at finding that 20% person for your most critical position, the technical lead (whatever you call them in your org or project).

If you look at all of the talent out there today, you will see a zillion candidates with extensive experience moving workloads onto the cloud etc. etc., which is a good and valuable set of skills. But those skills and similar tech skills are not what you need to build your core systems.

You need people with the following:

1-Domain experience (you don't want people that have been designing+building streaming video systems their entire career)

2-Experience extracting business requirements, and organizing and managing that information. This is an art that takes a long time to acquire.

The business will tell you they need an alert when inventory is too low, but the real question is why is the inventory low? You need to follow the chain back to the planning system where they are excluding transactions they should not be excluding.

3-Experience creating solutions (functional and technical) that meet the business requirements and other domain requirements not explicitly stated by the business as well as a reasonably pragmatic design that accounts for the various gotchas that a good designer will account for (otherwise you will play a painful game of whack a mole of small/medium issues for years and years never realizing it's because the design was not good enough)

Responding to my own post to respond to one of OP's questions:

> Alternative solutions we should explore.

When I am working with a vendor's app with critical gaps and I know the vendor will not solve the problem (because they don't have the talent or it's functionality that doesn't apply broadly to their market), then I try to work with them to just add a hook (on our dime) to link to our external custom functionality.

The easier you can make it on the vendor the more likely they will incorporate it. Typically I will design the interface of info in a way to make their lives as easy as possible to incorporate the results in to their systems.

Some examples where I used this very successfully:

1-Cubing/Cartonization for outbound orders - we have many unique requirements from our customers as well as from our internal business channels. Vendor calls our system, passes relevant info, we produce the result and return it, they do all of their normal app updates as if they were the ones that produced the result.

2-Picking/batching optimization - same issue, nobody has any out of the box optimization that supports all of our requirements and dependencies - same flow, we perform our own prioritization+optimization and return the results, they update their app/db.

3-Generalized Rules engine - most workflows are controlled with normal ERP style configurations in the app, but some require much more flexible logic, for those we had the vendor insert a call to our rules engine, they pass in key relevant data, we crunch it, we return the result, they update their app/db.

An example usage of this one is in our order routing across different DC's. The business can target all kinds of special conditions to support their business requirements (e.g. product X should ship from DC Y for special customers A, B and C due to some special processing in that facility).

4-Generalized external function - in one system we had the vendor add the capability to call an external function at any point in the workflow (they have configurable processes where multiple steps can be linked together). This one one is not designed to return anything to the calling system other than success or failure, it's more about inserting external actions within the workflow (e.g. external action might be a function in a separate system that is fully self-contained).

These are just a few examples but we've made use of it extensively. I think it's a really effective compromise when trying to work around vendors app limitations.

Agree with pretty much everything you said. It's the devil you know vs. creating a whole new devil you don't know.

I wonder if it's viable for OP's company to buy the company they depend on for this software, and then staff it up and get the bugs fixed. That way they retain the domain knowledge from this company, and they get everything they want done to be prioritized. This would also likely prevent any future competition if they own the company that's making this one-of-a-kind software.