Unifier Approval Workflow
A comparison of workflow models between Primavera Contract Management and Unifier
Primavera Contract Management and Unifier both have support for approval workflow, but the approach is significantly different between the two tools. This article will elaborate on some of those differences.
In Primavera Contract Management, each approval cycle can involve multiple people, with "approve in sequence" or "approve in parallel" workflows. Workflows are defined for each document on an ad hoc basis. Two different purchase orders could have completely different approvers, and even different approval models.
In Unifier, each workflow step is enacted by one and only one person. By definition a document can only be in a single state at a given time. To model more elaborate approvals in Unifier (for example multiple sequential approvers), you would need a more elaborate workflow, with more states and transitions.
Additionally, in Unifier, the workflow is defined at the business process level. They can't be defined ad hoc. This increases standardization at the cost of flexibility. You can get some of that flexibility back by defining multiple workflows for a business process. Also, you can make each workflow in Unifier do more with conditional branching. For example, a purchase order can automatically be routed for additional approval if the amount is over a certain value.
Another difference between the two systems is that only certain types of documents in Primavera Contract Management have workflow. Change Orders have them, but Potential Change Orders don't, for example. In Unifier, workflows are fundamental building blocks of the system, and they can be attached to any business process.
About the Author
Dan MacMillan - Integration Specialist
Dan has been developing software professionally for over 20 years, joining Emerald Associates in 2003. His experience includes accounting, supply chain management, drilling program management, project management, and contract management integration, automation and dashboarding elements.
Dan learned how to program computers as a child by watching his older brother making games on his Commodore 64. His interest in computers and programming drove him to teach himself BASIC, 6502 and 80386 assembly language programming, and then C so that he could write hobby programs. Moving from hobby to professional, Dan did his computer science studies at SAIT in Calgary.
In his first professional programming job, Dan had the autonomy to make mistakes, live with them, learn from them and fix them. He realized that quality in software derives, not from what it does, but from the way it is written, and yields benefits such as having fewer bugs, and being easier to read and change. On that project, Dan transitioned from programming hobbyist to craftsman with a “quality first” focus in his work.
