Organize / Design newScale forms by Service-Action or by Organization / Department?

[Hoan Trinh Hoan Trinh]

Organize / Design newScale forms by Service-Action or by Organization / Department?

My company has been using newScale 2006 for self-service ordering last couple years without a service catalog (being worked on).  The internal newScale development team has been guiding the customers to follow and design the newscale order forms by Service-Action, for example, "Email Account - Create", "Email Account - Remove", "Email Account - Modify".  Lately, we have been challenged by customer wanting a newScale form for their business unit where an end user can request one of three services listed in the form - Application, Database, and Data, and an Action listed in the form - Request, Modify, Remove, and Troubleshoot (see the attachment on the prototype form).

My questions are:

(1)  How do your company / department organize or design the newScale forms:  by Service-Action or other?

(2)  The technical impact of the answer to question 1:  configuration required effort, maintenance effort, testing effort.

(3)  End users  feedback  on either method?

Thanks.

[James Fuller]

Our philosophy has been to take it in the back-end to make it easy in the front-end.  How we do that is by combining as much of these type of options within a single service, allowing the end user the ability to make selections to order their service.

The technical impact is what you're concerned with, I'm sure.  Ideally, the more work/effort you put up front gathering and approving the business requirements and fulfillment requirements with the appropriate teams, the less administration you'll end

[Emir E]

we are redoing all our services from one gigantic (Add/Modify/Delete) form in to atomic services ...

2. Testing is more challenging

4. You loose ServiceImprovement/billing/etc functionalities

[Hoan Trinh Hoan Trinh]

Thanks for replies.  Any lessons learned from the experience?

[Darwin Hammons]

The lessons learned for our company have come from the migration from the old tool to RequestCenter. We have many complex (multi-purpose) forms and will attempt to use the strategy of building atomic services for hopefully 90% of the services offered. There will be cases where combining atomic services with the use of RAPI to build complex offering. We are just in the beginning stages of the migration but can see there are going to be maintenance nightmares if we do not stick to an atomic service methodo

[Ken Komara - Allstate]

Beside becoming a maintenance headache, it is much more difficult to report on and manage service performance when using one form for many different service requests.