What kind of custom software gets built around Vorne XL?

What do people ask us to build?

The requests are more repetitive than you would expect. A plant with Vorne XL boards already has the production numbers; what is missing is almost always a connection to something else, or a screen for a job the board was never meant to do. Sorted into categories, nearly everything lands in one of these five.

• Jobs pulled out of an ERP. The schedule already exists in SAP, Oracle, Microsoft Dynamics or something written in-house years ago. An integration reads the work order and puts the job on the line, so nobody is typing a job number that already exists in another system.
• Production data pushed back into a business system. Counts, downtime, reasons and labor context, written out to whatever does costing, scheduling or company-wide reporting, on a schedule rather than by export and email.
• Work orders raised from downtime events. A downtime past a threshold, with a reason code already on it, becomes a CMMS work order without anybody re-keying it. The interesting half is usually the return path: what maintenance did, back against the event that caused it.
• Operator workflows the board does not cover. Scanning a tool, a mold or a QR label to punch into a job. An hourly entry screen for a line with no board on it. Timers and alarms for a process that runs to its own rhythm. Role-based scan codes so a setup tech and an operator do not see the same buttons.
• Screens built for how your plant actually runs. An andon view for the shift meeting, escalation when nobody answers a call inside a set number of minutes, an operator scoreboard, or a view for a long-takt line where one cycle takes hours and a standard OEE screen is the wrong shape entirely.

Each one is a modest amount of software sitting on production data that is already being collected, which is the reason this kind of work is worth asking about at all.

What does it get built on top of?

Not a blank page. Collection from your boards is already running, and what it writes is already normalized and shared by every part of the suite:

• production counts, states, downtime, reasons, rejects and comments
• jobs, parts, schedules, teams, employees, technicians and labor context
• custom operator forms, hourly entries and daily direction board inputs
• legacy Vorne V1 history, converted so it reports under the same names as V2 data
• custom fields and comments mapped into the reporting tables where a plant needs them

The connections outward exist too. OEE IntelliSuite already reads and writes SQL Server and PostgreSQL, REST APIs, Excel imports, ERP and scheduling feeds, MQTT, SMTP for mail and an SMS provider where alerts need it, plus Power BI, Tableau and Apache Superset on the reporting side. A new integration is usually a new endpoint on a road that is already paved.

What makes this cheaper than it sounds?

Custom software has a reputation earned mostly by the parts nobody asks for, and those parts are already in place here.

Ingestion. Getting data off the plant floor, from two generations of hardware, is the part that quietly eats a project. It is already running before your request starts.

The data layer. One schema, shared, with the dimensions already on the records: device, job, part, shift, team, employee, reason code. A request that would otherwise begin with modelling production data begins with a join instead.

The deployment path. Server install, on premises or in the cloud, containers or native Windows, backups, role-based access, a remote update path and an offline bundle for sites with no internet. A custom feature ships down the same road as the rest of the suite rather than becoming a second thing for IT to host, patch and back up.

What is left is the thing you actually asked for: the call to the ERP and the field mapping behind it, the operator screen and what it writes, the rule that decides when a downtime event becomes a work order. That is a smaller piece of work than the same request would be against a plant with no data layer under it.

What does a request look like?

It starts with a workshop that maps the pain point, the data flows and what a good outcome would be worth, and it moves to a prototype built against your own sample data, so the first thing you look at is your plant rather than a demo. From there it is iteration until it fits.

The most useful thing you can bring is not a specification. It is the workaround: the spreadsheet somebody maintains, the clipboard that gets typed up on Friday, the number that gets re-keyed into a second system because the two do not talk. Those describe the real work better than a feature list does, and they are also how you tell whether the finished thing worked.

A request that would help every plant running Vorne boards tends to become part of the product rather than a one-off, while something genuinely specific to your process stays specific to you. It is worth asking which one you are in early, because it changes what happens to the thing over the next few years.

Where does it run, and who gets to see it?

On the same server as the rest of OEE IntelliSuite, wherever that sits: inside your network, or hosted for you. Debian is preferred for Linux installs, Windows Server 2022 is supported where plant IT requires it, and Docker is the preferred install mode with native Windows available for sites that cannot run containers. Everything is reached through a browser, so operators, supervisors and executives get to the same system from desktops, tablets, phones and floor displays without a desktop client to deploy.

Role-based access decides who sees what, which matters more than usual with custom work: an operator scan screen and an executive summary are typically the same project seen from two ends. The server requirements, the network access a deployment needs and the offline installation path are all listed on the technical specifications page.

What do you end up owning?

Something that behaves like part of the suite rather than a bolt-on. It runs on your server, against your database, and the records it writes land in the same tables OEE Explorer and OEE Pulse already read, so reporting on the new thing is not a second project. A custom operator screen that captures a reason or a count shows up in the dashboards because it is writing to the same place everything else does.

The reporting half of this question - custom reports, printable output, scheduled delivery and getting the data into a BI tool your analysts already use - is covered on the sibling page about custom reports from Vorne data. If the request is really about asking questions of the data rather than building a screen, the page on AI for Vorne data is the closer one. And the service itself, from integration through to bespoke development, is described on our services page.