BPM Handbook

Process Innovation (HCM & Finance): Business Process Management Staff Handbook

This staff handbook provides team-level guidance for employees within Process Innovation (HCM & Finance): Business Process Management. It explains how the team operates, how responsibilities are organized, how work is governed, and how team members contribute to consistent, data-informed, and transparent business process management across the University of Arkansas.

Self-Development, Training & Growth

BPM team members are expected to actively participate in their own development. Training and skill-building should support the employee’s current role, assigned responsibilities, future growth, and the team’s expanding service scope across HCM and Finance.

Development Expectations

• Complete assigned onboarding and training activities by the expected timeline.
• Use the training tracker to document progress and identify outstanding needs.
• Participate in self-assessments honestly and use results to guide development conversations.
• Maintain an IDP that supports current responsibilities and future growth.
• Ask questions and seek clarification when training content does not connect clearly to assigned work.
• Apply learning through real BPM assignments, documentation, analysis, testing, and stakeholder support.

Applied Learning Approach

BPM development is not limited to formal training. Team members are expected to learn through guided participation in active work, including ticket review, discovery preparation, meeting support, documentation drafting, process analysis, testing coordination, and post-implementation review. Applied learning should be supported by feedback, examples, templates, and supervisor guidance.

How We Operate as a BPM Team

BPM uses a structured operating model to manage work consistently from intake through closure. The operating model supports transparency, prioritization, documentation, stakeholder accountability, and readiness for implementation. All BPM work should be managed in a way that allows leadership, team members, and partners to understand status, ownership, risks, decisions, and next steps.

Core Operating Principles

BPM 11-Phase Lifecycle

The BPM lifecycle provides a consistent structure for managing Workday business process projects and change requests. Not every work item requires the same level of effort in every phase, but each phase should be considered when determining readiness, ownership, and next steps.

Systems, Tools & Access

BPM uses multiple systems to manage intake, documentation, collaboration, Workday analysis, implementation support, testing, reporting, and communication. Team members are expected to use the correct system for the correct purpose and maintain accurate records in official systems of record.

Access Expectations

• Access should be requested only when needed for assigned responsibilities.
• Team members should not share passwords, credentials, files, exports, or data outside approved access paths.
• If access is missing, the team member should notify their supervisor or designated access coordinator.
• If access appears broader than needed, the team member should raise the concern for review.
• Access to confidential information does not create permission to view, use, or share information outside legitimate job requirements.

Ticket Governance & Work Tracking

BPM work must be tracked in a way that supports transparency, accountability, reporting, prioritization, and leadership visibility. TeamDynamix is the primary system used to track BPM work, while Jira is used when Workday Support Services involvement is needed for Workday configuration, support, or issue resolution.

Ticket Management Expectations

Parent / Child Ticket Governance

Parent and child ticket relationships are used to organize related work, improve reporting, and support leadership prioritization. When a request becomes part of a larger initiative, the parent ticket should serve as the primary driver for reporting and prioritization. Child tickets should provide detail for specific business processes, functional areas, testing needs, or implementation tasks.

• Use the parent ticket to summarize the overall initiative, roadmap priority, executive status, and major decisions.
• Use child tickets to track process-specific details, assigned owners, testing items, documentation, or discrete workstreams.
• Do not create duplicate parent tickets for the same initiative unless there is a clear governance reason.
• When reporting priority, status, or workload, parent ticket logic should be used where applicable to avoid overstating related child work.
• Child tickets should remain linked to the appropriate parent ticket until closure.

Jira Coordination

When Workday Support Services is needed, BPM may support the preparation, clarification, or tracking of Jira tickets. Jira tickets should include clear requirements, business context, testing needs, related TDX references, and any known dependencies. Approved central team members are responsible for submitting Jira incidents or requests when required by the established support model.

Prioritization & Roadmap Management

BPM uses prioritization to ensure that limited team capacity is directed toward work with the greatest institutional value, operational need, compliance importance, or strategic alignment. Prioritization supports transparency and helps leadership understand what work should proceed, what should wait, and what requires additional clarification.

Prioritization Factors

Roadmap Expectations

• Prioritized HCM, Finance, Academic, and Payroll work may become part of the BPM roadmap for the fiscal year.
• Leadership priority decisions should be documented and reflected in the appropriate ticket records and reporting tools.
• Roadmap items should be reviewed for parent/child ticket relationships to support accurate status reporting.
• Work may be reprioritized when institutional needs, compliance requirements, dependencies, or team capacity change.
• Not every request becomes a project. Some requests may become change requests, future backlog items, documentation updates, or may be redirected to another service path.

Decision Documentation

Prioritization decisions should include enough context to explain why work is moving forward, why it is delayed, or why it has been redirected. Documentation should include the decision, the rationale, the owner, the date, and any follow-up required.

Discovery, Analysis & Solution Design Standards

Discovery, analysis, and solution design are central to BPM work. These activities ensure that BPM understands the current process, identifies root causes, documents requirements, evaluates policy and governance considerations, and designs solutions that are practical, compliant, and sustainable.

Discovery Standards

• Identify the business problem, not only the requested solution.
• Document the current-state process, including roles, pain points, exceptions, policy references, and known workarounds.
• Identify stakeholders, SMEs, decision-makers, and groups affected by the process.
• Review related tickets, Jira items, Workday configuration, transaction patterns, and existing documentation when available.
• Determine whether the issue is a process problem, policy issue, configuration need, training gap, communication gap, reporting need, security issue, or a combination of these.
• Document assumptions, open questions, risks, dependencies, and decisions.

Analysis Standards

Analysis should help explain what is happening, why it is happening, who is affected, and what options exist for improvement. BPM analysis may include workflow review, stakeholder mapping, RACI review, transaction analysis, ticket trend review, bottleneck identification, policy alignment review, and comparison of current-state and future-state options.

Solution Design Standards

• Design solutions that address the root issue rather than only the presenting symptom.
• Confirm that the future-state process has clear roles, owners, decision points, and escalation paths.
• Document functional requirements in a way that WSS, SMEs, testers, and stakeholders can understand.
• Identify impacts to training, reporting, security, integrations, communications, and downstream processes.
• Confirm that the proposed solution can be tested and validated before deployment.
• Document options considered when the solution requires leadership or governance decision-making.

Testing, Readiness & Deployment Standards

Testing and readiness activities help confirm that a change works as intended, meets documented requirements, supports the business need, and can be implemented with minimal disruption. BPM may coordinate or support testing depending on the scope of the work, the teams involved, and the implementation path.

Testing Expectations

• Testing should be based on documented requirements, known scenarios, and expected outcomes.
• Test scenarios should include common use cases, exceptions, and high-risk process paths when applicable.
• Testing results should be documented clearly enough for another team member to understand what was tested, what passed, what failed, and what needs follow-up.
• Issues identified during testing should be logged, assigned, tracked, and retested after correction.
• Testing should not be considered complete until open issues are resolved, accepted, or formally documented as out of scope.

VAT and UAT

Readiness Checklist

Before deployment or implementation, BPM should confirm that readiness needs have been reviewed. The level of readiness documentation may vary based on scope and risk.

• Requirements are documented and understood.
• Testing has been completed or an exception has been approved.
• Open issues have been resolved, accepted, or documented.
• Stakeholders understand the change and any required actions.
• Knowledge base articles, job aids, or training materials are updated when needed.
• Communication needs have been identified and assigned.
• Deployment timing and dependencies are documented.
• Post-deployment monitoring or stabilization expectations are clear.

Deployment and Stabilization

Deployment should occur only after the team confirms that the change is ready to move forward. During stabilization, BPM should monitor for issues, collect feedback, verify expected outcomes, and support needed adjustments. Stabilization activities should be documented in the applicable ticket or project record.

Documentation & Knowledge Management Standards

Documentation is a core responsibility of BPM work. Strong documentation helps the team maintain continuity, support transparency, reduce rework, train new team members, communicate with stakeholders, and preserve decision history.

Documentation Expectations

Knowledge Base Standards

• Knowledge base articles should use clear titles, plain language, and consistent formatting.
• Articles should identify the audience, purpose, and steps or guidance being provided.
• Articles should be updated when a process, system behavior, policy reference, or routing expectation changes.
• Articles should avoid outdated screenshots, broken links, or unclear ownership.
• Internal articles should support team consistency, while public or campus-facing articles should support user understanding and service accuracy.

Version and Maintenance Expectations

BPM documentation should be reviewed when processes change, when a project closes, when an issue reveals unclear guidance, or when onboarding materials no longer reflect how the team operates. Documentation maintenance is part of operational quality, not an optional final step.

Stakeholder, SME & Partner Engagement

BPM work depends on effective collaboration with central teams, departments, subject matter experts, Workday Support Services, functional leaders, and other partners. Team members are expected to engage stakeholders in a way that is structured, respectful, clear, and outcome-focused.

Engagement Expectations

• Clarify who needs to be involved and why.
• Invite the right SMEs early enough to prevent rework or incomplete requirements.
• Prepare for meetings with clear objectives, questions, and desired outcomes.
• Document decisions, risks, action items, and unresolved questions after discussions.
• Use RACI when ownership, consultation, or approval responsibilities are unclear.
• Respect partner expertise while maintaining BPM’s responsibility for process structure and governance.

Common Partner Groups

Meeting and Follow-Up Standards

Meetings should result in documented outcomes. When BPM facilitates or coordinates a meeting, the team member should capture key decisions, action items, owners, due dates, unresolved questions, and any follow-up needed. Meeting notes should be stored or summarized in the appropriate ticket, document, or project location.

Governance & Policy Alignment

All BPM work must align with University of Arkansas and University of Arkansas System policies. BPM does not create or override policy but is responsible for ensuring that business processes operate in alignment with policy requirements and that any identified gaps or conflicts are escalated appropriately.

Official Policy Source

All official policies must be accessed through the University policy portal:

https://policies.uark.edu

BPM Policy Responsibilities

• Identify policies that apply to the business process under review.
• Ensure proposed changes align with policy requirements.
• Document policy references when relevant to discovery, design, or decision-making.
• Escalate policy conflicts, ambiguity, or gaps to the appropriate central office.
• Avoid interpreting policy beyond the team’s scope; coordinate with policy owners when needed.
• Include policy alignment considerations in testing and readiness review.

How Policy is Used in BPM Work

🔒 Confidentiality & Data Protection Requirements

Process Innovation (HCM & Finance): Business Process Management operates with access to sensitive institutional data across Human Capital Management, Finance, Payroll, Academic operations, reporting systems, and analytics environments. Protecting this information is a fundamental responsibility of all team members and a condition of employment.

BPM Standard: All data accessed through Workday, reporting tools, integrations, data pipelines, dashboards, tickets, or analytics environments must be treated as confidential unless explicitly designated otherwise.

Confidentiality Statement

All Personal Identifying Information (PII) and Protected Health Information (PHI) – which includes medical and financial information, employee records, and student records – as well as financial and operating data of the University of Arkansas and any other information of a private or sensitive nature is confidential. Confidential Information must not be read or discussed by any employee unless pertaining to his or her specific job requirements.

Examples of inappropriate disclosures include:

• Employees discussing or revealing PII, PHI or other Confidential Information to friends or family members.
• Employees discussing or revealing PII or PHI or other Confidential Information to other employees without a legitimate need to know.
• The disclosure, without consent, of an individual’s presence in a hospital or other medical facility that may reveal the nature of the individual’s illness to an unauthorized party without a legitimate need to know.

Disclosure of PII, PHI, or other Confidential Information to unauthorized persons, and unauthorized access, misuse, theft, destruction, alteration, or sabotage of such information are grounds for immediate disciplinary action up to and including termination.

Employee Confidentiality Agreement

I hereby acknowledge, by my signature below, that I have read and understand the Confidentiality Statement and will follow it. I understand that PII, PHI and other Confidential Information to which I have knowledge and access in the course of my employment with the University of Arkansas is to be kept confidential, and this confidentiality is a condition of my employment. I understand that Confidential Information shall not be disclosed to anyone under any circumstances, except to the extent necessary to fulfill my job requirements. I understand that my duty to maintain confidentiality continues even after I am no longer employed. Further, upon termination with the University of Arkansas, I shall return to the University all Confidential Information.

I understand the University of Arkansas’s guidelines pertaining to the use and disclosure of PII, PHI, and other Confidential Information. I understand that approval must first be obtained before any disclosure of PII, PHI, or other Confidential Information not addressed in the guidelines and policies and procedures of the University is made. I also understand that the unauthorized disclosure of PII, PHI, or other Confidential Information is ground for disciplinary action, up to and including immediate termination.

I am aware that, in the event I breach this agreement, the University may pursue all remedies against me.

Acknowledgment

Performance, Accountability & Continuous Improvement

BPM performance is measured through the quality of work delivered, adherence to governance standards, effectiveness of collaboration, and ability to support institutional outcomes. Team members are expected to contribute to a culture of continuous improvement by identifying opportunities, learning from outcomes, and applying lessons to future work.

Performance Expectations

• Maintain accurate and up-to-date documentation.
• Meet agreed timelines or communicate delays early.
• Support stakeholder understanding and readiness.
• Demonstrate ownership of assigned work.
• Apply BPM standards consistently across projects and requests.
• Seek feedback and apply it to improve performance.

Continuous Improvement Approach

Onboarding Completion & Next Steps

Upon reviewing this handbook, new BPM team members should complete onboarding activities, confirm access, and begin applying what they have learned through assigned work and guided support.