Without doubt, the most valuable feature is the ability to operate and work within Microsoft Word, our default word editing program. When the rest of the organization is dealing with templates and Word format, it's nice to be able to use that as the system artifact that goes into generating the end results. We used to get our requirements in Word templates, then we'd have to do the costly conversion to XSLT templates, which was time-consuming and we never got it to look the way the business wanted it according to the Word template.
So the biggest the day-to-day benefits are working through a medium that can be universally used from requirements gathering all the way to a run-time and generating documents.
We're now live with one instance of generating documents, we're committed, and we've got the architecture and infrastructure to add more templates and migrate our old ones. We didn't realize it initially, but once we setup up our platform around Docmosis, we've registered new templates, merged data, and created PDFs.
When I get requirements and other templates from my business counterparts, the time to development has been reduced dramatically. My initial projections are that we have an 80% improvement in that process. Any company's engineering and software teams of specialists are highly prized and valuable, so they no longer have to do the boring, tedious content creation of translating Word templates into XSLT. Docmosis has really freed up our capacity to do some real work.
I've shared with Docmosis a list of improvements they could make, and they've been very customer-centric and responsive. They don't always deliver what we ask, but they're very conscientious about responding to us. We have some pretty onerous requirements, but they timely respond.
Because we're not using the cloud version, using the Java library version instead, we'd like more visibility and control of load balancing for owned and private cloud.
Another thing I'd like to see is the ability to more dynamically add converters on the fly. They help generate the PDFs.
Also, this was something they suggested and we wholeheartedly agree: a more simplified install process or consolidated JAR. The reason for that is because otherwise you're installing all these other dependencies related to either OpenOffice or LibreOffice, so that that could simplify the ramp-up to deployment.
The barcoding functionality also needs improvement, specifically a more robust handling of it. Right now, they allow for 1D barcodes, so eventual integration of 2D barcodes would be well-received.
I'd also like some sort of native support for e-signatures.
Fonts, I think, are a little tricky, and so the workaround, on the client-side, is just to address it at a system level, make sure your core system has the fonts necessary for your documents. That's completely okay, but for teams that are operating a couple of layers up in the stack, if they don't have access to that system level, installing fonts and so on just becomes a little more difficult and requires more coordination. That'd be an opportunity to make it simpler or the developer, because the developer isn't always the system manager.
I use a feature within Docmosis to embed templates within templates, and there are some technical limitations, and I don't think it's Docmosis' doing, but there are some limitations in operating with headers and footer when you're using that feature. I get the rationale for not being able to make enhancements around that, but I would want enhancements around that nevertheless.
We engaged with them as far back as the fall of 2014, and we began implementation around that time. But the project, internally as a company, was on and off, due to our systems team's capacity to handle the project. For all of 2015, we had it semi-implemented, but didn't actually have it in a live environment until January of this year. It depends on where you mark the start, but from when we went live with it in a production capacity would be from January 2016. But we've been getting support from them, we've been a paying customer, since last year.
We've had no issues with deployment.
We did some load testing of our daily thousands and thousands of documents, specifically of our spammer, to make sure we could handle the volume. There were no problems at all with the stability of Docmosis.
If we ever ran into a bottleneck, we could always initiate more Docmosis core servers with additional converters. There have been no scaling issues there.
Support@docmosis.com has generally been very responsive, usually within a day of an email. They're willing to jump on a call, too, to walk us through more complex scenarios. I appreciate their courage as they try to understand what we're trying to accomplish, why we're doing it, and try to think outside the immediate problem to see if the direction we're going in makes sense. They take a very consultative approach.
I don't remember the name of the solution, but it required XSLT formats as templates and then to merge data, which was very powerful and performant, but it didn't have load capabilities, converters, and it required translation from Word to XSLT, which was consuming our dev resources. We wanted to free up our developers from that kind of task to focus more on valuable activities.
Docmosis will free up developers, but then the burden falls on someone else, so more attention needs to be spent on Word templates themselves. They need to be as true to the desired form as possible to get a good end result. Someone must take charge of managing and creating Word or OpenOffice templates.
Also, there are a few deployment flavors -- cloud, web service for on-premise, and Java libraries. So picking the right mix is key.
