Went through shopvox, corebridge, cyrious, signtracker and onprintshop. they all organise the floor the same way

[Foremander]

Been lurking here a long time. spent about 15 years in signs, installs then sales then production, and now i work on software for shops.

I spent a few weeks properly going through every shop management system in this trade, because i wanted to understand why nobody I talk to seems happy with any of them. shopvox is the default for most small and mid shops, line item jobs on a stage board you configure yourself, each stage assigned to somebody. the complaint i hear most often is not that it lacks anything, its that theres too much of it and the setup is a slog. Corebridge is aimed higher, an approved estimate goes down a fixed sales to design to production chain, deep templating, powerful but heavy and priced like enterprise software. cyrious control is heavier again, a proper workflow engine built for big shops and costed accordingly. signtracker is where a lot of people land after bouncing off shopvox, simple and cheap, and it wins by doing less. onprintshop comes at it from the storefront end, orders drop in from the web and flow into production stages.

what jumped out at me is that all five organise the floor exactly the same way. a job gets pushed through stages in order, design then proof then print then finish, and every one of them argues about who does that best. not one of them asks whether stages are the right idea in the first place.

because a banner and a set of channel letters on the same order do not go through the same steps in the same order, and a good chunk of production happens at the same time rather than one thing after another. every shop i worked in ended up bending the job to fit the software instead of the other way round.

the one that used to drive me mad was material. wed have five or six jobs on the go all printing on the same roll of IJ35, but they were all sitting at different stages so the board never showed them together. you would load the roll monday for one job, unload it, load something else, then load the same roll again wednesday for a job that was three feet of print. nobody could see it because the software was organised around where a job was in its life instead of what it actually needed. i reckon we wasted more time on setup and changeover than on the printing.

so the question im actually asking. does anyone genuinely run their floor in stages, or does everybody quietly work around it? and if you threw stages out, what would you want in their place?

ill be straight with you, i build software in this space so ive got a dog in this fight. im not pitching anything here; I'm trying to find out whether im wrong about this before i go any further.

 

[netsol]

yes they do, in much the same way that our warehouse client's large warehouse software all deals with "pick zones" (for product category/departments)
in much the same way. we had to customize our systems ourselves

 

[Foremander]

yes they do, in much the same way that our warehouse client's large warehouse software all deals with "pick zones" (for product category/departments)
in much the same way. we had to customize our systems ourselves

That's a good comparison, hadnt thought of warehousing but your right its the same thing. a pick zone exists so the picker isnt walking the whole building four times for one order. thats exactly the bit im on about, you batch by where the stock is, not by which order its for.

same logic on a shop floor. if six jobs are all going on the same roll you want to see those six together and run them once, not load the roll monday, take it off, put it back on wednesday. the software organises around where a job is in its life instead of what it physically needs.

whats interesting is warehousing worked that out ages ago and our lot never did.

What did you end up having to customise? curious whether it was the grouping itself or just reporting on top of it.

 

[GB2]

Great thought process.....I had the same idea once when I had a ton of jobs and tight deadlines for everything so I had to improve my efficiency. I simply put all my jobs in an Excel sheet and then I was able to sort them by process and material so I could group them together like you describe. That way I was able to print all the intermediate vinyl jobs first then the high performance, then laminate all the intermediate, then switch once to laminate all the high performance, etc. It worked great for me then but it was a quick solution to an immediate problem that didn't integrate with anything so I didn't use it long term but the idea is good and should be an easy thing to work into a full system.

By the way, I'm checking out your free Channel Letter tool and I'm looking forward to being able to use it with custom logos and lettering, any ETA on that? I haven't had the chance yet but I'll be looking at your full package software soon. There have been many discussions here about software of this type but as you know, the perfect solution hasn't surfaced yet. Many years ago I created some fairly robust programs using FileMaker Pro and I know it's capable of doing the job but creating it yourself these days is a daunting task. I'm hoping you'll be the one to solve the problem! Thanks!

 

[Foremander]

Great thought process.....I had the same idea once when I had a ton of jobs and tight deadlines for everything so I had to improve my efficiency. I simply put all my jobs in an Excel sheet and then I was able to sort them by process and material so I could group them together like you describe. That way I was able to print all the intermediate vinyl jobs first then the high performance, then laminate all the intermediate, then switch once to laminate all the high performance, etc. It worked great for me then but it was a quick solution to an immediate problem that didn't integrate with anything so I didn't use it long term but the idea is good and should be an easy thing to work into a full system.

By the way, I'm checking out your free Channel Letter tool and I'm looking forward to being able to use it with custom logos and lettering, any ETA on that? I haven't had the chance yet but I'll be looking at your full package software soon. There have been many discussions here about software of this type but as you know, the perfect solution hasn't surfaced yet. Many years ago I created some fairly robust programs using FileMaker Pro and I know it's capable of doing the job but creating it yourself these days is a daunting task. I'm hoping you'll be the one to solve the problem! Thanks!

That's the funny thing about this problem, everyone who actually feels it ends up building the same spreadsheet. sorting by process and material then running the whole column at once is exactly it. all the intermediate first, then the high performance, one laminate change instead of five. the spreadsheet works because it answers the only question the floor actually has, which is what can I run together right now.

and what you said about it not integrating is exactly why it dies... the excel version knows what to batch but it doesnt know when the proof got approved or what got paid, so you keep it alive by hand and one busy week kills it. thats the part im trying to make automatic. the batching view should just fall out of the job data instead of being its own thing you maintain.

good timing on the channel letter question, custom logos went in this weekend. in the cut files section theres a toggle, typed text or upload artwork. feed it an svg of your logo and it does the whole thing now, sizes it to your letter height, measures it for the estimate side too, so perimeter, face area, led count and power supplies all come off your actual artwork, and each separate piece of the logo gets its own cut files and coil marks. only catch is it wants proper vector art, text converted to outlines and strokes expanded, same as youd send to a plotter.

filemaker pro is a deep cut ha. a lot of shops ran on home built stuff like that for years because nothing off the shelf ever fit. if you remember what yours did well id genuinely like to hear it, the things people built for themselves are usually the best spec document there is.

 

[WildWestDesigns]

Many years ago I created some fairly robust programs using FileMaker Pro and I know it's capable of doing the job but creating it yourself these days is a daunting task. I'm hoping you'll be the one to solve the problem! Thanks!

In most instances, finding solutions is usually best for inhouse. Unless one can deal with the generality that most commercial software take (regardless of what application one is thinking of) and shoehorn it in, doing something bespoke is typically the better way to go. Only exception to that is if there is a robust and well documented plugin API. Can be daunting yes, but there isn't any shortage of tools to help with that (sans what passes for "AI", if trying to learn some API at the same time, "AI" can do more harm and take longer trying to figure out what it's hallucinating and what it isn't).




Spreadsheet type of stuff is good for single purpose type of work. It doesn't really scale as easily when trying to make it more robust. It has it's place though. Now, I'm not one to actually like using someone else's leased infrastructure. Even though "you" are creating the product, in this case, it's tied to someone else's infrastructure and if something happens to that access (for whatever reason), bye bye solution.

 

[Foremander]

In most instances, finding solutions is usually best for inhouse. Unless one can deal with the generality that most commercial software take (regardless of what application one is thinking of) and shoehorn it in, doing something bespoke is typically the better way to go. Only exception to that is if there is a robust and well documented plugin API. Can be daunting yes, but there isn't any shortage of tools to help with that (sans what passes for "AI", if trying to learn some API at the same time, "AI" can do more harm and take longer trying to figure out what it's hallucinating and what it isn't).




Spreadsheet type of stuff is good for single purpose type of work. It doesn't really scale as easily when trying to make it more robust. It has it's place though. Now, I'm not one to actually like using someone else's leased infrastructure. Even though "you" are creating the product, in this case, it's tied to someone else's infrastructure and if something happens to that access (for whatever reason), bye bye solution.

The leased infrastructure point is the strongest argument against every saas in this space and most of them earn it. the test i keep coming back to is the exit door. can you walk out with everything, not just a customer csv but every order, every line item, every price, the comments, the whole history, in files a human can open?? most of the big ones export customers and invoices and quietly keep the rest, which turns bye bye access into bye bye business. any vendor that wont show you the full export before you sign is telling you something.

on bespoke, i half agree. the happiest shops ive talked to ran their own thing for years, filemaker, access, one glorious excel monster. but every one of them had the same weak point, the solution was tied to one person the way saas is tied to one vendor. the guy who built it retires or leaves and the shop is holding software nobody can touch. gb2 said it himself, it worked great but he didnt use it long term. one person is also leased infrastructure, the lease is just their patience.

so the honest version of the choice is pick your dependency. a vendor with a real export and a documented api, or a person with a spreadsheet and a memory. both can burn

 

[WildWestDesigns]

The leased infrastructure point is the strongest argument against every saas in this space and most of them earn it. the test i keep coming back to is the exit door. can you walk out with everything, not just a customer csv but every order, every line item, every price, the comments, the whole history, in files a human can open?? most of the big ones export customers and invoices and quietly keep the rest, which turns bye bye access into bye bye business. any vendor that wont show you the full export before you sign is telling you something.

Even if it's a full export, how does it translate into importing into the next deal? Even a flat database file like a .csv export can still hiccup importing it to the next program. Or a .json one (although probably not as common as an exchange format like .csv is for this type of discussion). What true db format are they using? The vendor can be using a bespoke one for their SaaS or they could be using sqlite (maybe not if it's online though, too many concurrent users will tank that, I like sqlite, I use sqlite for a couple programs that I have (not really related to this endeavour, one is a stop motion app (although it could be used for 2D traditional animation or even archiving as well) and the other is a db for a collecting hobby that I have and my source control uses it as well (the first two I wrote, the last was written by the guy that actually wrote sqlite as well).

on bespoke, i half agree. the happiest shops ive talked to ran their own thing for years, filemaker, access, one glorious excel monster. but every one of them had the same weak point, the solution was tied to one person the way saas is tied to one vendor. the guy who built it retires or leaves and the shop is holding software nobody can touch. gb2 said it himself, it worked great but he didnt use it long term. one person is also leased infrastructure, the lease is just their patience.

Well, that is partly a problem of not having an exit strategy for if that employee retires, quits or is fired. Even if no exit plan exists, technically all the files are still there versus probably not having everything on any exported file.

so the honest version of the choice is pick your dependency. a vendor with a real export and a documented api, or a person with a spreadsheet and a memory. both can burn

There may be real export, but is it a complete export? What is the exchange format? Not all information is going to be able to translate in that exchange format. Will the next tool that one uses, be able to even take that exchange format as is and import it into the new tool? So while there may be "real" export, in the end, it may not mean much because not everything may be exported in to that exchange file and/or the next tool that one uses, may not import it correctly.

If one is going to make a bespoke, non trivial tool, there has got to be documentation of some level. Both in terms of code and usage. Doxygen can handle code concerns, the user manual concern I think would be handled by something like Sphinx (I think that's for Python though as a 1st class citizen, if doing say a C/C++ program, probably going to use something else or some middleman to get Sphinx to work with those languages).

Now, I wrote my in house tooling (the ones that I felt reasonably sure that I could write and not have it mess up my business anyway, I wasn't going to reinvent some things) and that's different when the boss is doing it versus an employee, so there is that as well. There is way too many FOSS and OSS tools out there to make this not quite the hard endeavour that one may think, even using C/C++ (of course, I would start getting a MVP first and after that point, worry about leaning it a bit, I have some C/C++ apps that use web front end as a gui, but all processing is done on bare metal(most of the time using C), there is a hit doing the web gui part, but it's quicker to iterate and keep code separate versus some immediate mode monstrosity, even with cimgui).

 

[Foremander]

Even if it's a full export, how does it translate into importing into the next deal? Even a flat database file like a .csv export can still hiccup importing it to the next program. Or a .json one (although probably not as common as an exchange format like .csv is for this type of discussion). What true db format are they using? The vendor can be using a bespoke one for their SaaS or they could be using sqlite (maybe not if it's online though, too many concurrent users will tank that, I like sqlite, I use sqlite for a couple programs that I have (not really related to this endeavour, one is a stop motion app (although it could be used for 2D traditional animation or even archiving as well) and the other is a db for a collecting hobby that I have and my source control uses it as well (the first two I wrote, the last was written by the guy that actually wrote sqlite as well).


Well, that is partly a problem of not having an exit strategy for if that employee retires, quits or is fired. Even if no exit plan exists, technically all the files are still there versus probably not having everything on any exported file.


There may be real export, but is it a complete export? What is the exchange format? Not all information is going to be able to translate in that exchange format. Will the next tool that one uses, be able to even take that exchange format as is and import it into the new tool? So while there may be "real" export, in the end, it may not mean much because not everything may be exported in to that exchange file and/or the next tool that one uses, may not import it correctly.

If one is going to make a bespoke, non trivial tool, there has got to be documentation of some level. Both in terms of code and usage. Doxygen can handle code concerns, the user manual concern I think would be handled by something like Sphinx (I think that's for Python though as a 1st class citizen, if doing say a C/C++ program, probably going to use something else or some middleman to get Sphinx to work with those languages).

Now, I wrote my in house tooling (the ones that I felt reasonably sure that I could write and not have it mess up my business anyway, I wasn't going to reinvent some things) and that's different when the boss is doing it versus an employee, so there is that as well. There is way too many FOSS and OSS tools out there to make this not quite the hard endeavour that one may think, even using C/C++ (of course, I would start getting a MVP first and after that point, worry about leaning it a bit, I have some C/C++ apps that use web front end as a gui, but all processing is done on bare metal(most of the time using C), there is a hit doing the web gui part, but it's quicker to iterate and keep code separate versus some immediate mode monstrosity, even with cimgui).

You're right that the export is only half of it, the import on the other side is the unsolved half. theres no standard exchange format for shop management and there never will be, so "will the next tool take it" is always going to be a per vendor answer. The least bad version ive landed on is flat csv plus json, one file per table, named columns a human can read, so worst case a person can rebuild in anything with an afternoon of copy paste. and the practical fix ive seen for the import side is vendors writing importers for each others exports, which only happens when shops demand it before signing.

..and yeah, the boss writing the inhouse tool is the version that survives, no argument. the graveyard is full of the employee written ones.

 

[Foremander]

Been chewing on something since my reply to GB2 about the batching view falling out of the job data. Worked out what the actual mechanism is. i was going back and forth with the shop i build this around and the owners line was "substrate isnt technically something to do". every system treats everything on a job as a task. substrate, laminate, cutting, all the same kind of checkbox. but a job isnt waiting on 6mm coroplast the way its waiting on weeding, its made of 6mm coroplast. split those two apart, stuff you do vs stuff its made of, and the batching view just appears. filter the floor by what jobs are made of, tick off only the actual steps, no spreadsheet to maintain. none of the 5 systems i went thru make that distinction anywhere, which might be why they all fall back to stages.

Question for anyone running substrates. do you set thicknesses up as seperate products (4mm coro, 6mm coro, 10mm all their own) or as options on one coroplast product? we just switched from options to products after a two week arguement and im curious if thats universal or just this one floor.

 

[WildWestDesigns]

The least bad version ive landed on is flat csv plus json, one file per table, named columns a human can read, so worst case a person can rebuild in anything with an afternoon of copy paste.

That is fraught with data entry errors though, especially depending on how much rebuilding is involved. I had a closed source database program that allowed csv export, but it was formatted wrong for my program. Python script to handle that and create an updated .csv file per table to import into a sqlite3 db. If doing a handful of files, that's one thing. I had over 2300 tables to do this for. Even the time it took to get the script right, I still came out ahead of trying to do it by hand.

The importers, quite likely aren't going to get that, that would make it too easy for customers to float between each of them. Anything that would make things easier for the customers moving about, isn't going to do for them as a business model. There will always be some con to the software that will cause the customer to leave. That juice isn't going to be worth the squeeze for them. And just even on the technical side of things, nothing is standardized and that makes for exporting -> importing a non trivial issue. That would have to be solved and I would still imagine that some things would remain behind.

 

[Pauly]

We have stages but nothing like on those software.

Our stages are operations for machines eg Print (per printer), Kiss Cutting, Through Cutting, Welding, Eyeletting, QC. Each operation has their list of machines.
Our operators will work at one or more machines depending on the workflow

Each product defines the workflow, banners, stickers, boards all have their own workflow. you wont get banners in a kiss cut operation.
So when an operator is finished that operation, they press done, and it goes to the nest, no need to figure out where it goes next.

 

[Foremander]

We have stages but nothing like on those software.

Our stages are operations for machines eg Print (per printer), Kiss Cutting, Through Cutting, Welding, Eyeletting, QC. Each operation has their list of machines.
Our operators will work at one or more machines depending on the workflow

Each product defines the workflow, banners, stickers, boards all have their own workflow. you wont get banners in a kiss cut operation.
So when an operator is finished that operation, they press done, and it goes to the nest, no need to figure out where it goes next.

That's the first one I've heard described that routes by machine instead of by stage. and the part that jumps out is the product defining its own workflow, so a banner cant end up in a kiss cut queue. every one of the five i looked at makes you build one pipeline and then shove everything through it, so the pipeline ends up being the lowest common denominator of everything you sell.

the bit im really curious about is the nest. when an operator presses done and it drops into the nest, does the system group whats sitting there by material on its own, or does a person still decide what runs together? thats the exact gap i couldnt find filled anywhere. routing i can see how youd build. its the batching everyone seems to leave to a human.

also, is that something you had built or bought off the shelf? printtrade sounds like the volume where you either find something that fits or you end up writing it yourself.