Best Practice: Out of Box or Custom Application?

[amkatulak]

Creators,

What is your criteria for creating a custom application vs trying to make an existing app "fit" by making some tweaks?

I was just approached by the business and they are looking to use ServiceNow to manage Site Transitions.  

My first thought was to use Project Management, but then I started to wonder if it might be a better idea to extend Project Management into a custom application that can be entirely tailored to these specific projects.  

I'm just looking to see what everyone's thoughts are on this, and how others would approach it.

Thanks in advance!

AK

[casey_stinnett]

I believe that a cost analysis is in order. Whenever the solution is between custom and already made, you need to ask yourself a few questions:

(1) How long will building my own app take?

(2) Will the app I make be better (in terms of efficiency, security, and options) than the one already made?

(3) How long will tweaking an existing app take me?

(4) What are the possible negative consequences of tweaking an existing app (think of how far it will get from the original in the future as you develop it further with more requirements)?

(5) Are there other features that I don't know about yet in the already made app that can suit my needs?

Does this help to point you in the right direction?

[david_legrand]

Note: this is in addition from the Casey's post

In addition of the cost (and that an important point), I might even go higher in the "strategy and governance" personally because here we should have a large overview and medium/long term perspective  

Summary:

I use to say :

• "Making this kind of architecture choice is still an art and not a science"
• "Similar processes (and real work beneath it) can be supported by the same applications, if the processes are different, maybe it'll be easier (and cheaper in maintenance) on a longer perspective to have different applications"
• "If we use one application for several processes, these processes should remain close together and shouldn't evolve in opposite direction"

In your case of "Site transition" (CreateNow or Project Management), all the questions remain in the predictable future

• What are the challenges of the department and of the company?
  • We need to define the process as we work because the process is very specific
  • We need to define a common framework with all the departments to share the vocabulary / "way to think" / "way to work" because the communication between the department is a key for the site transition process
• Will other people use Project Management for other purpose?
  • Yes and their processes are similar to the Site Transition
  • Yes but their processes are different to Site Transition
  • No
• Will the "Site transition" a stable process or something who could evolve after the implementation?
  • If other departments will use the same application: "Will the processes stable or everyone will evolve in another direction"
• What are the needs in term of security?
  • We work alone, only us are able to see our data
  • We work with all the other departments and we have communication issues with them because our processes don't fit, we should use similar processes
• What about the process owner / team?
  • I'm strongly independent, I want to take the decisions for my process and I'll make sure my process will evolve as I say (because we have a business value to make it evolving)
  • I want to use the enterprise best practices, if the best practices of the company say "A" and we do "B", we'll do "A"

Example 1:

Incident in ServiceNow is "IT incident". We could say "I don't care, I want to use the incident form for 'HR incident' (or why not Nuclear Plant Incident) so I do all the tweaks" to do so and I'm saving a lot of time.

But now the IT department is saying "Oh, ServiceNow is nice, could we use it as well?". We do agree that "IT Incident" and "Nuclear Plant incident" aren't the same at all. So, what do you do?

1. You have a new instance for IT department (so you have 2 instances)
2. You have a new instance for IT department and then you have to make a transition project to import the "Nuclear Plant Incident" on the new instance (and in a new application) and you enrage that people didn't do a "Nuclear Plant Incident" at the beginning
3. You stay on the first instance and you use "domain separation" to modify the process on a new domain
4. You stay on the first instance without domain separation and you customize the view, the business rules... to make it work

Personally, i'll be for the 2nd choice.

Example 2:

I have HR processes and now I have to onboard "Payroll" people.

I have a meeting with HR directors and Payroll directors and I have their commitment to say (after process review/assessment) "We engage each other to use the same process and we'll make a strong governance to make the process evolution together"

==> having HR process and Payroll process on only one application could (not in all cases) work and it could help to save money.

So in your case, i would study:

1. Enterprise strategy around ServiceNow (and more specifically around Project management)
2. Enterprise strategy around process / vocabulary standardization
3. (as Casey) Site Transition process and predictable evolution
4. (as Casey) Site Transition report requirements and predictable evolution
5. (as Casey) Security requirements
6. (as Casey) Cost to modify and cost to build from scratch

regards,