Had an interesting use case for EDMCS come up recently, and wanted to share some of the process of designing EDMCS objects/features to support a business process.
Use case:
The customer currently uses Word/Excel documents on a SharePoint site to handle requests for ERP segments [including adding, updating, or inactivating]. These documents have anywhere from 10-35 questions for the requestor to fill out, including the date of the change, descriptions of why it is needed, and other check boxes to give the approvers / data stewards more information. This information is used to update the COA in ERP, EPM, and also update code-combinations and other integrated systems.
We wanted to prototype this use case in EDMCS to see if this could replace, and enhance this process.
Proposed value:
- Use EDMCS as a data collection “form” for future GL Segment Change requests; provides an end-user portal to visualize the changes
- Provide governance and approvals in a traceable system vs. a collection of spreadsheets
- Approvers/Data Stewards can review, approve, reject, or push-back requests if they need more information
- Allow for putting in front-end validations and checks into the system so requestors have to enter accurate and complete data sets before the request can be submitted
- Reduces “back and forth” of emails/form documents in today’s process
- Enforces correct & complete requests before review
Custom Application & Properties
Since this process doesn’t directly integrate to a target application with a delivered adapter, I began by registering a Custom Application Adapter in EDMCS and setting up the Dimensions. This particular situation, the customer has a different form by GL Segment, so that is what I used as a baseline for my design. For now, I set up each Dimension as a list; but could also do a hierarchy if the requestors know the parent/rollup points.
On the Node Type setup, I began working on designing properties to capture the information in the form. I prefixed each custom property with “REQ.” before the property name, which helps when searching/referring to properties throughout the build. I now know that every property with this prefix is related to my GL Requests. See below example, named Custom.REQ.AllowForPostingActuals.
Based on the information, I used different property templates to get the field to meet the business requirement:
- Boolean for when they wanted to capture a check box or a Yes/No about the topic. (example below)
- String with List Values for when the user needed to pick a specific value.
- Memo for when the user had to add a few sentences about details.
- Date for when the user needs to pick an effective date or request date.
- Node for when the user needed to pick a valid GL Segment. This one is nice, as it makes sure the user picks something that is a valid GL Segment (node) that lives in EDMCS.
Some of the properties I created could be used across Dimensions, so I made sure to use generic naming convention standards that could be used in multiple Node Types.
Viewpoint Customization
In addition to setting up my properties to help end-user experience and to collect the data needed, I customized some of the features on the Viewpoints.
In EDMCS, if you inspect the Viewpoint and go to the Properties tab, you can see there is the Namespace & Name column displaying the system name, but also a field for customizing the Label (left-most). This is where you can rename your properties to be “prettier” for the end-user experience. You can also add more information in the Description field to give the user more detail on what input they need to provide.
In this example, I reminded the user that the Description had to be less than 80 characters; which is something I enforce on the Property setup See the End User view below.
If the user types more than 80 characters, they’ll get a validation error, as well:
Another feature I leveraged was setting properties to be “Required” – this is a great way to ensure that the end users are filling out the form completely for what is needed. If a property marked “Required” is not filled out, the user will get a validation error.
This setting is actually on the Node Type (Request Cost Center) > Properties Tab. Simply select “Edit” and then mark which Properties should be required. This also visually shows in the Form/Viewpoint with an asterisk for required fields.
This was a great enhancement to the current process, as the Word/Excel forms did not have preventative measures built into them to ensure the end-users are providing complete information.
I may also leverage Custom Validations in this process – such as preventing deletions or limiting the input on specific items based on business logic. However, at this point, most of the validations I need to check for come with configuration of the properties (like limiting description length).
Security, Workflow, and Other Considerations
Next, we will need to define a workflow; and configure the security and approval policies to support the new business process.
We will need to define the number of field users that would be requesting the new GL Segments (by segment) and assign them to be able to request new values in the Viewpoints. These users would only be able to see the Viewpoints they need to to make requests (i.e “fill out the form”).
In this case, a specific group of individuals make the call on if a new GL Segment is needed from these requests, and will assign the GL Code. That means that an enrichment needs to occur, as well as an approval. This group will be defined as Data Managers for Permissions so they can make updates to the requests, and an Approval Policy will be enabled for this group to Approve, Reject, or Push-back the requests from the field.
Eventually, these requests will fire subscriptions in the GL Maintenance Views to ease transfer of the approved data directly into our Oracle Cloud Financials GL hierarchies.
This is a sizable business process change and needs to be reviewed with your internal training team and organizational change management (OCM) teams to ensure adoption. There are new users that will need to have some preliminary training to fill out this “form” within EDMCS, and ensure that business process documentation is updated.
Final Thoughts
Although there is more work to be done; by enabling EDMCS to be a point of entry, EDMCS is able to to guide the process, enforce data quality, reduce time to entry, apply governance, and provide valuable insight into changes over time that can be easily pulled/extracted for review.
There are a multitude of other possibilities to replace manual document request forms. What ideas do you have?
Thanks for reading!
-Kate
hyperionbarbie.wordpress.com 