Friday, January 30, 2015

Why would I buy Nintex?

In my blog post ECM Governance - Post 5, I mentioned that I should post about Nintex and how to determine an ROI for the purchase; I bet anyone who knows me never thought I would get a post out this soon...

So, first things first, lets talk about Nintex. 

First, I want to point out that I do lead a large SharePoint practice in Western Canada and we are a Nintex Platinum partner, but that said, I am not driven by sales here, I am driven by a piece of software that can make your life and SharePoint solution better.

Nintex is a company, not a product, in reality Nintex offers several products, but when SharePoint people (like me) talk about "Nintex" they are referring to two products (Workflow and Forms) that are often bundled together as a BPM solution for SharePoint.  These are the products I am going to examine and hopefully explain how you can gain value and save money in their use.

What does Nintex do that SharePoint doesn't?

First Workflow...

Now this is a question I get a lot, while the answer was simple, it has recently changed.  I used to say that Nintex doesn't do anything you can't already do with SharePoint, but now I have to say it doesn't do a lot more, but it has some additional functionality when it comes to integration.  So now you are saying, if it doesn't add much, why would I buy it?  Well that answer is simple, while SharePoint offers extensive workflow capabilities out of the box, you need to be a developer or employ a developer to leverage it.  Out of the Box (OOTB) SharePoint needs either SharePoint Designer or Visual Studio to create anything but the basic workflows in the platform, while the workflow development tools are there, unless you know C# I don't see you creating workflows anytime soon.

Nintex changes all that, it takes what is a programming interface in SharePoint and makes it a graphical interface, then it adds in all the parts that take a lot of effort to program, like auditing, tracking and performance monitoring and throws them in.  The first advantage this gives is that it allows developers to mentor power users in the creation and maintenance of their own workflows (though this still takes a lot of time and effort because it still follows programming logic).  It also allows your developers to reduce the time to create a workflows by a factor of three (from my experience) and finally, everyone can see the workflow and each step as it executes, tracking the time for each step, the decisions made and auditing each step in real time.

Then Forms...

Until recently I would answer that forms provide a nicer interface than the Microsoft tools (InfoPath)and an easier way to brand your forms consistently, but since Microsoft announced the deprecation of InfoPath, Nintex Forms no longer has a Microsoft equivalent to compare, making it and other third party tools a requirement if you want to customize the form user experience.

Ok, so how can we calculate an ROI?

Now I am going to simplify the math I am using, I will first go through my basic Math assumptions and rough estimates (over estimated) cost for Nintex (Forms and Workflow), then you can see where the break even should be.

Assumptions

  • Nintex Cost $15000 USD per Web Front End (WFE) = C
  • You have two WFE Servers (for load balancing and redundancy) = S
  • The average C# workflow will cost $10000 (from my experience it is usually more) to develop = W
  • Nintex Reduces your development by a factor of 2 (as mentioned above, my development team has typically realized a factor of 3) = f
  • We will not account for the value added by Forms or by Power Users who learn to develop workflows.

The Formula

Where X = Number of Workflows to Breakeven

XW = CS + (XW/f)
10000X = 30000 + 5000X
5000X = 30000
X = 6

The teacher always said, Show your work, lol.  Now realize by over estimating the cost Nintex, underestimating the cost of a C# workflow and under estimating the factor of improvement, we achieve a worst case scenario or 6 business processes before you begin saving money, the reality is most of my clients realize it between three and four workflows created.  I guess the question to you is, how many workflows do you have that could be automated and is there any advantage to them being automated?

If you want to find out more about Nintex, you can go to their website:  http://en-us.nintex.com/

If you want to follow me on twitter I am @DavidRMcMillan or @DevFactoPortals, feedback is always appreciated, good, bad or indifferent. 

Thursday, January 29, 2015

ECM Governance - Post 5

I think it is official, I suck at blogs, but I promise to try to post more (not saying I will), but one thing you can be sure of is a tweet when I do.  I seem to be getting worse at this, rather than better, blog posts always end up being low on my priority list and the time between seems to increase, not decrease.  Today I wanted to finish off the definitions of the different principles and then we can move on from there, hopefully in a more timely manner.

Collaboration Principles

Collaboration principles are principles that describe the way in which we plan on using the Team, Project and other collaboration site capabilities of the solution. It should include things like the site design, which lists and libraries are standard, the security roles used in collaboration, Content Types for templates and anything else you want to control in the collaboration portion of your solution.

Collaboration principles are about the control of who can do what, where and when. They provide a foundation for collaborative interaction and as such are always used in your solution in some way. As an example of a Collaboration principle, I have included "Collaboration sites will inherit the top menu navigation from the parent site", which encompasses the fact that collaboration sites are more loosely controlled than portal sites and control revolves more around the user experience.  Later when we examine the application of policies, we will see that as we move down the hierarchy from portals to collaboration sites and then to my sites, we change from highly structured and restrictive control to a looser user enabled control, but more about that later.

Collaboration sites will inherit the top menu navigation from the parent site
Principle
Collaboration sites will inherit the top menu navigation from the parent site.

Implication
To maintain a consistent user experience, the same top menu is used throughout all collaboration sites, Site Administrators will have no control over navigation.


Business Process Principles

Business Process Management is a core function that every ECM needs and SharePoint is no exception.  The one caveat I have to say is that SharePoint sucks for creating workflows and forms, thank goodness they deprecated InfoPath, Nintex does a far better job in the forms area and makes it possible for power users (with training and mentorship) to create some complex workflows.  The developer will never disappear for the complex workflows, but his work is minimized, providing a better return for the organization.  Come to think of it, the ROI of a tool like Nintex seems like a good topic for another blog post, stay tuned for that too, lol.

Anyway, regardless of the tools used, BPM needs some structure around how workflows, integrations and forms are created, where they are stored, how they are executed and anything else you think will need a boundary around.  In this example I have created a principle for the management of alerts and notifications, which fall under business process management.  The principle is intended to reduce the overhead of managing alerts and notifications, but ensuring users are responsible for managing their own alerts and notifications.  Coupled with this principle are other principles around training for users and principles for notification and alert creation.

Each user is responsible for the management of alerts and e-mail notifications
Principle
Each user is responsible for the management of their own alerts and e-mail notifications.
Implication
While anyone can assign alerts to others, each user is responsible for the maintenance of their own alerts and notifications. Each user needs to ensure they receive the notifications they need.


Esthetic/Site Design Principles

Now I changed the name of this, many ECM governance practitioners will call this user experience, but for me, it is more than just the user experience and encompasses the brand, navigation, search style guides, master pages, XSL transformations and anything else that affects the look and feel of the solution, including site and page templates.  These rules are often the most important because they directly affect the user experience and adoption; no one like an ugly site. 

I remember a developer that once worked for me, he had recently come from China and I asked him if he could brand our product SharePoint site.  He said "yes" and with a slight head bow, immediately set to work.  He ended up spending the evening at home working on it, so when I came in the next morning, he proudly presented me with a SharePoint team site branded in bright red and gold, or as his cohorts called it the ketchup and mustard brand, very much like the 1980's McDonald's I grew up loving... but alas there was no Hamburglar anywhere on the site.

That little story illustrates why this is so important, every user has a different idea when it comes to look and feel and if I had simple used a governance principle that said his brand had to align with the corporate style guide, there would never have been an issue; well maybe.  I have included a couple examples in this case, one that identifies the importance of user experience, the other ensures no one thinks they can make up their own brand.

Prefer Findability over Authoring Convenience
Principle
Ensure that “findability” governs design decisions – optimize metadata and site configuration to provide the best value for the end-users, not just the content contributor.
Implication
In situations where design trade-offs must be considered (more metadata versus less, information above or below “the fold”, duplicating links in multiple places), decisions should be made to make it easier for end users rather than content contributors. “Findability” means designing sites so that important information is easily visible and that navigational cues are used to help users easily find key information. It also means using metadata to improve accuracy of search results. Both the “browse” and “search” experience for users will guide design decisions in initial site development and modification over time.

All publishing and collaboration sites will be consistently branded
Principle
All publishing and collaboration sites will be consistently branded.
Implication
In order to maintain consistency in the look and feel of the intranet, standardized brands will be used for collaborative and publishing sites and will not be modifiable by the site owners.

Content Principles

Where the Esthetic principles are the most important principles for user experience and adoption, content principles are about making the solution fit for purpose, after all this is an ECM we are taking about (emphasis on the "C"). In reality, my experience has proven that the content principles will out number all the other principles combined, why, we can every content type will need principles to define it. Whether we are talking about a metadata field, a vocabulary, taxonomy, document, list, image, template page or alert, it is all content and that means that principles that affect any part of the system will probably affect the content principles.

Because content principles are such a vast area, I have included several examples to help you get started, but understand even in the beginning this category is the main part of a governance document. Some of these you have already seen, which reinforces my point of overlap, yet I am sure you can see how they apply to more than one category.

All content is owned
Principle
All content must have a clearly identified “owner”.
Implication
Users need to know who to contact if content on a site is out-of-date or inaccurate. The content owner is accountable for all the content in a site and for ensuring it is up-to-date. Each site should have a clearly defined owner that is visible on the main page of each site.

Maintain a single source of truth
Principle
All content exists in only one location.
Implication
This means that the official version of a document is posted once by the content owner. For the reader’s convenience, users may create a link to the official copy of a document from any site, but should not post a “convenience copy”. Users should not post copies of documents to their personal hard drives or My Site web sites if they are already on a site.

In situations where some documents or records need to be available offline due to a very slow or inconsistent connection to the SharePoint sites, SharePoint Workspace can be used to make these records available offline.

Use built-in versioning
Principle
Edit documents in place. Do not download or make copies for editing, if possible.
Implication
Version control will be enabled in document libraries where prior versions need to be retained during document creation or editing. If prior versions need to be retained permanently for legal purposes, “old” versions of documents should be stored as records. Documents should be edited in place rather than deleted and added again, so that document links created by other users will not break.

Sponsors/Owners are Accountable
Principle
Site Sponsors/Owners are accountable, but everyone owns the responsibility for content management.
Implication
All content that is posted to a site and shared by more than a small team will be governed by a content management process that ensures content is accurate, relevant, and current. Site Sponsors/Owners are responsible and accountable for content quality and currency and archiving old content on a timely basis but site users are responsible for making Site Sponsors/Owners aware of content that needs updating.

Business Intelligence Principles

Business Intelligence principles encompass the use and presentation of BI data, reports, dashboards,  charts, graphs and KPIs.  They are intended as with any other principle to provide both consistency and ease of management, with the later being very important.

In this example, we define a principle that ensures we are controlling access to the BI tools, which require an enterprise license in SharePoint.

The Business Intelligence Centre can only be accessed by the BI User role
Principle
Only the BI User Role will have access to the BI Centre
Implication
To control the Enterprise license in SharePoint the BI Centre exists in it's own web application and can only be accessed by users who have the proper licensing.  The BI User role has been configured to ensure compliance with the Microsoft licensing model.

So anyway, this one took a long time, so I made up for it with more content, but I am trying to get my MVP, so I may need to blog a lot more, it doesn't do a lot of good knowing a bunch of stuff if I am not going to share it with the world.  Got to change the IT world, one client or reader at a time.

ps.  follow me on twitter, @DavidRMcMillan, I will post articles and where I will be speaking there.