We have a huge ERP system we built in-house in 201...
# sdf
b
We have a huge ERP system we built in-house in 2011 that didn't scale at the rate of growth (neither did our Quickbooks) so we start in Netsuite in 2017 with core financials and have been pushing CRM and Project data from our internal system to Netsuite after they're awarded. Now we're in the process of moving all of our purchasing functionality into Netsuite followed by CRM/Project Management, but we have a pretty sophisticated and proprietary way in which we estimate our work so we're looking to rebuild our ERP scaled down and specializing in this method (our field service is unlike anything I've seen before, so that will likely end up there too). Anyway, it's going to be another ground-up implementation with full Netsuite Integration, and I'd just love to be able to build a robust configurable application rather than the relatively static thing we have where if someone wants to add a field to a form, it requires engineering hours.
a
Not sure if this totally captures what you're looking for, but you might be able to make that dynamic by using record.getFields() then getField() on each of those field IDs, which would allow you to know the field ID/type/label/etc of any field on the record, so if there are new ones you could then have the proprietary software on your end add new fields based on that.
b
@amy I don't want to create records in our system based on what we have in netsuite. I want to rebuild netsuite 😉
a
lol fair enough! sounds like an interesting project, hope you're able to get there without too much pain on the netsuite side. i'd be curious to hear what your eventual solution is - i've worked on a number of different clients with weird needs around projects/services
b
won't be a lot of netsuite integration apart from simple pulling and pushing of data into stuff that's already in Netsuite
this will be a PHP application. Won't be doing too much more than a few suitescripts to handle some workflow stuff
the rest of the CRUD will happen via SuiteTalk
s
That all sounds pretty standard. I am just curious where the need for building a mock NetSuite would come into play with that architecture? Are you concerned about performance or availability of a cloud-based system?
b
We do things that Netsuite doesn't and nobody has made suiteapps or even integrated tools for. That leads us to believe there may be a niche to fill, but our current architecture is far too closed to be a viable product for cloud-based sale or anything.
so we are looking at re-architecturing the entire process to make it more "configurable" than "customizable"
and I've been super impressed with the way Netsuite does it
s
I see. A lot of companies integrate with NetSuite and have a configurable bundle that allows access to those external services for customers already using NetSuite.
b
right
that's probably where we'll go with this
possibly integrate with other ERPs in the future -- start as a Netsuite-specific vendor
but right now, we just want it to work well for us as a seamless experience between Netsuite as our new CRM and this updated tool for the project estimating
I just don't want to have to spend engineering hours to add a field to a form anymore lol
a
Is the estimating most of what you can't do in NS for projects? We're in the process of scoping out adding more estimation to NS for projects right now, but it's pretty heavily reliant on scripts so I know of at least one company who would be interested if you ever go to market 🙂
b
Well, we're an industrial contracting company that does things a lot differently. Most general contractors will have one or two trades departments in house (Electrical, usually) and then they will subcontract out the rest of the trades (pipefitting, concrete, painters, machine movers, etc). We differentiate ourselves by having all of the trade departments in-house and we subcontract out nearly nothing. This allows us to cut costs and win more projects because we don't have the overhead of subcontracted labor. The way we do estimates is as if each trade department were its own COMPANY. We, basically, send out subcontractor requests internally. We assign "estimates" to our department estimators. Sales gathers the requirements for the project, gleans as much information as possible for each trade, and then each trade estimator receives the RFQ information. Each estimator then completes their own estimate (all at the same time) and then submits the data back to Sales who then does the discounting and quoting to the customer. So basically, every "quoting" piece of any software has sales doing the configuring, pricing, and quoting. If you want to assign someone else to do the configuring, you can only have one person working on it at any given time without fear of data getting overwritten. So looking at CPQ software, nothing fits our mold since each trade does its own CPQ back to our own sales team.
Then our field service is unique in that the information provided in the department estimates (labor, material, equipment, etc) is then pulled into the scheduling and work order/ticketing for the project. So when the guys get in, in the morning, they can see what project(s) they are assigned to, what other crews are assigned to that project, what the scope of work is for the entire project and what is expected for that day, etc...
Our internal ERP is a monolith of related data. Everything flows completely natively from each "module". But that monolith mentality is what got us into the failure to scale predicament we're in now.
We are talking to a couple of vendors but only one has been able to demo something that at least leaves us hope that we may not need to do a ground-up build on our end with perfect integration into netsuite