For manufacturers running abas ERP
We have trained AI on the abas database and on EDP, so it posts transactions, queries the database, and runs Infosystems the way your own people would. That groundwork is done, so the custom apps, chatbots, reporting and live dashboards you need get built on top of it.
We do not replace abas. We build on it, and everything runs in your accounts.
Why this is faster with us
Any AI project on an ERP spends its first weeks the same way: working out how the system stores things, how to work with it safely, and what can be trusted. That work is done for abas.
We built our own tools for abas and ran them against the real database until the AI could find things reliably. Where the same fact lives in more than one place, we know which one to trust.
The AI is trained on EDP and uses it the way your own people use abas: posting transactions, querying the database, and running Infosystems. Everything goes through the interface abas provides, so its own rules and validation still apply.
Reporting against the abas database crawls. We keep a SQL database in sync with abas and point reports and dashboards at that instead, so the numbers come back in seconds and the load never lands on abas.
The gap
Every abas shop we walk into has some version of these three problems.
Want margin by customer, by cell, this month. That is a ticket, a partner call, or a wait. So people export to Excel instead, and the real number ends up on somebody's desktop.
Real-time reporting is the number one gap abas users name
Scheduling in a spreadsheet. Quoting in a separate file. Quality on paper. abas has the orders, but the things that decide whether a job makes money live outside it.
One job, five systems, no single view
The data is in there. Answering "which open jobs are past due and over quoted hours" still means somebody knows exactly where to click, and has time to go do it.
Answers take days, decisions do not wait
What we do
Six things, in whatever order helps you most. Most manufacturers start with two.
MCP is the standard that lets AI assistants talk to real systems. We build one for your abas install, so Claude, ChatGPT, or Copilot can answer questions straight from live abas data.
In practice
Someone types "show me open jobs for Ridgeline past their promise date with hours over quote." The assistant queries abas through the MCP server and answers with real records, not a guess. Read only by default. Any write is scoped, logged, and turned on deliberately.
Tablet apps for the floor, quoting tools for estimating, portals for customers. Purpose built for one job, reading and writing to abas through the REST API.
In practice
A shop floor tablet where an operator clocks a job, flags a scrap part, and uploads a photo. It posts back through the abas REST API, so abas core logic and your customizations run exactly as they do in the client.
A chatbot grounded in your abas data plus your own documents. Work instructions, travelers, spec sheets, customer history. It answers from your reality, not the internet.
In practice
Inside sales asks what a customer ordered last time and what it shipped at. Answer in seconds, sourced from abas records and quote history, with links to the underlying records so anyone can check the work.
Backlog, throughput, on-time delivery, margin by job. On a wall screen and on a phone, refreshing on their own. Not a deck somebody rebuilds every Friday.
In practice
Same numbers on every screen in the building, pulled from abas on a schedule you set. When a job slips, the floor sees it that morning instead of at month end.
abas connected to the rest of your stack. CRM, shipping, EDI, accounting, and the spreadsheets your team will not give up. Data entered once, showing up everywhere it should.
In practice
An order lands in the CRM, and abas gets it without anybody retyping it. The shipment posts back, the customer gets a notification, and accounting sees it the same day.
Every place a person copies a number out of abas and into something else, or out of something else and into abas, is a place we can automate.
In practice
Vendor confirmations that arrive as PDFs get read, matched to the PO in abas, and posted. Exceptions go to a human. The other ninety percent stop being anyone's morning.
Not sure which of these matters most for your company? That is what the first call is for.
Under the hood
No screen scraping, no bot clicking through the client at 2am. We use the interfaces abas gives you.
2 to 4 weeks
from first call to something live in your business
20 to 40+ hrs
of monthly re-keying removed in a typical engagement
0
changes required to your abas core or upgrade path
Questions
No. abas stays your system of record and keeps doing its job. We build the layer on top: the dashboards, the apps, the AI, the connections to everything else you run. Most ERP replacement projects overrun and a majority miss their goals. This is deliberately not that.
It should not, because we do not touch the abas core. We work through the abas REST API, abas Connect, and exports, which are the supported interfaces. What we build lives outside abas, so an upgrade changes what is behind the interface, not the interface itself. We test against your sandbox before anything goes live.
Whichever route your install supports. The abas REST API for real time reads and writes, abas Connect for routed message exchange, SOAP for older systems, and scheduled CSV, XML, JSON or XLSX exports when the API is not available to us. We look at your specific version and licensing on the first call and tell you which one applies.
MCP is the open standard for letting an AI assistant use a real system safely. An MCP server for abas means your team can ask questions in plain English and get answers out of live abas data, with every request scoped and logged. It is the difference between an AI that guesses about your business and one that reads your actual order book.
Usually only briefly, to confirm API access and licensing. We are not trying to replace your abas partner and we are not competing with them for the ERP work. We take the projects that sit outside what a partner typically builds.
No. Most of the manufacturers we work with have one IT person, or none. We handle the build, the deployment, and the documentation. What we need is a few hours with the people who actually run the business, and someone who can approve access to abas.
Two to four weeks for the first working piece. We move fast because we work from your live abas data instead of months of interviews. The worst re-keying is usually gone inside the first two weeks.
Let's talk
Thirty minutes. You show us how abas is set up and where the spreadsheets took over. We tell you straight what we would build first, and what it would take.
Read next
Other systems we build on
Epicor Kinetic
MCP servers, custom apps, AI chatbots, and live dashboards built on the Epicor Kinetic REST API, BAQs, and Epicor Functions.
SYSPRO ERP
MCP servers, custom apps, AI chatbots, and live dashboards built on SYSPRO e.net and OData. We keep SYSPRO as your system of record.
Global Shop Solutions
MCP servers, custom apps, AI chatbots, and live dashboards built on Global Shop Solutions through GAB, the database, and its Web API.
Made2Manage
MCP servers, custom apps, AI chatbots, and live dashboards built on Made2Manage through its Web API, SQL Server, and SSRS.
All ERP work