Liberty University Business Case Study

DescriptionBMIS 603
BPMN ASSIGNMENT INSTRUCTIONS
OVERVIEW
In the BPMN assignments, use your analytical and modeling skills to improve business
processes. After reviewing the provided business scenario, recommend efficiency and quality
improvements through your writing and modeling. Models should focus on key business
processes but be comprehensive.
INSTRUCTIONS
For each BPMN Project, review the process documentation and complete these 4 steps:
1. Process Prospectus
a. After review of the process, submit a prospectus that:
i. defines the major business processes
ii. describes the major processes in detail
iii. describes how you will model the processes
c. Minimum of 1,000 words
d. Minimum of 5 scholarly and modern journal articles that support new methods
of modeling, unique to this section only
2. “As-Is” Process Diagrams
a. Using BPMN, create the process model that:
i. includes all major business processes
ii. uses the correct BPMN standards
iii. includes all activities in the proper sequence
iv. includes all decision points
b. Minimum of 500 words justifying the diagram designs
c. Minimum of 4 scholarly and modern journal articles that support the design
decisions and/or methods
d. Uses Aris Software Diagrams to thoroughly detail several relevant processes
i. Must include screenshots of each diagram with an operating
system date/time and a unique identifier of your computer
3. “To-Be” Process Re-engineering Diagrams
a. Using the prior diagram as a basis, re-engineer the process and create a diagram
that:
i. improves and optimizes the business processes
ii. includes costs
iii. includes benefits
iv. includes risks
b. Uses Aris Software Diagrams to thoroughly detail several relevant processes.
i. Must include screenshots of each diagram with an operating system
date/time and a unique identifier of your computer
c. Costs, Benefits, Risks Analysis. Line item financial analysis and budgets
are necessary to support the re- engineering diagrams
ii. Minimum of 500 words
Page 1 of 2
BMIS 603
iii. Minimum of 4 scholarly and modern journal articles that support new
methods of financial and risk analysis in business modeling, unique to this
section only
4. Process Evaluation
a. Using your reengineering diagram, you will submit an evaluation that:
i. is accurate and explains the reengineering
ii. is written in a professional manner
iii. summarizes the entire BPMN process using modern methods developed in
the last 3 years.
b. Minimum of 1,000 words
c. Minimum of 5 scholarly and recent journal articles that support new methods of
modeling, unique to this section only
Your document should meet the following criteria:
• Contain appropriate headings
• APA Style
• Acceptable citations are scholarly peer-reviewed journal articles, theses, and dissertations
Aris Express Software Installation Instructions
In this course, you will be using ARIS Express, a free business process modeling software for
faculty and students. Use the following link to complete the steps below: (See Resources section
for link)








Create an ARIS account, using your Liberty University email address. Other email
address domains like yahoo, gmail or hotmail will not be accepted. In order to download
the ARIS Express Student Version, your Liberty University email will be used to validate
your enrollment at an officially recognized university.
After creating the account, confirm your Liberty University email address within 48
hours.
Before downloading the software, read the License Agreement for the Student Version.
Download the ARIS Express software.
Review the Frequently Asked Questions.
Read the installation information in the Download Package.
Install the ARIS Express software.
Get help, if needed, from the ARIS Community and Support Group. Do not contact the
Liberty University helpdesk regarding ARIS Express software. Liberty University does
not support this software.
Note: Your assignment will be checked for originality via the Turnitin plagiarism tool.
Page 2 of 2
Policy and Procedure Manual for the Meteor Network
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
POLICY AND PROCEDURE MANUAL
Table of Contents
CHAPTER 1. OVERVIEW…………………………………………..………….
Page
1
The Importance of a Policy and Procedure Manual…………………..…………
Defining Policies and Procedures..………………………………………..………
How this Manual is Organized..……………………………………………..…….
1
1
2
CHAPTER 2. THE METEOR NETWORK………………………..………….
3
Meteor Users……………..……………………………………………..…………
Meteor Providers………………………………………………………………….
The Meteor Federation Model…………………………………………………….
Mission Statement…………………………………………………………..………
Vision Statement………….…………………………………………………..…….
Strategic Objectives………………………………………………………………..
Critical Success Factors……………………………………………………………
Administrative and Operational Organization Chart……………………………
Roles and Responsibilities…………………………………………………………
4
4
4
7
7
7
7
9
9
CHAPTER 3. NETWORK POLICIES…………………………………..…..
10
Meteor Advisory Team Participation Policy ………………………….……..…..
Network Usage Policy …………………………………………………………..…..
Access Provider Eligibility Policy………………………………………………….
Data Provider Eligibility Policy…………………..……………………………….
Authentication Agent Eligibility Policy……………………………..…………….
Participant Privacy & Security Policy…………………………………………….
Removal from the Network Policy…………………….…………………………..
Use of Data Policy…………………………………………………………………..
Use of Data Exception Approval Policy……………………………………………
Disaster Recovery Policy…………………………………………………………
Dispute Resolution Policy ………………………………………………………….
10
10
10
10
10
11
11
11
11
11
11
CHAPTER 4. NETWORK PROCEDURES…………………………….
13
Meteor Registration Process – Access Providers………………………………..
Meteor Registration Process – Data Providers………………………………….
Meteor Registration Process – Authentication Agents….………………………
New Participant Review Procedure……….………………………………………
Authentication Level Setting Procedure……………………………….…………
Production Problem Reporting and Resolution Procedure………………………
Code Donation Review and Distribution Procedures……………………………
APCSR Alias List Review Procedure…………………………………………….
Meteor Registry Change Procedures…………………………………………….
Removal from the Network Procedure ……………………………………………
13
15
16
17
18
19
20
21
22
23
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page i
Use of Data Exception Procedure………………………………………………….
Source Code Change Procedure…………………………………………………
Security Breach Reporting Procedure…………………………………………….
Dispute Resolution Procedure…………………………………………………….
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
24
25
26
27
Page ii
Chapter 1. OVERVIEW
The Importance of a Policy and Procedure Manual
Most organizations today recognize the value of having a policy and procedure manual that governs the
general operations and fiscal practices of the organization. The Meteor™ Advisory Team (MAT) has
created this Policy and Procedure Manual to go beyond governance and to systematically address all
aspects of the Network operations. Administering a Network such as Meteor is complex, and written
policies and procedures contribute to the long-term stability and safety of the Network by:
• Providing documentation of the Network’s vision and operating principles
This Policy and Procedure Manual provides a clear statement of the mission, values, and vision of the
Network and provides the framework that defines the Network’s operating principles and processes.
• Providing staff with clear guidelines on how to administer a program
This Policy and Procedure Manual provides detailed, step-by-step instructions on how the Network is
administered and clearly defines roles, expectations, and routine operating guidelines.
• Addressing risk management issues
This Policy and Procedure Manual is fundamental to risk management of the Network because it
provides clear and explicit instructions on how every part of the Network is administered. This allows
Network participants and administrators to safely, effectively, and consistently manage the Network.
Defining Policies and Procedures
Policies and procedures represent the sum total of foundational decisions, requirements, and activities
needed to run the Network. All major program operations are captured in the following policies and
procedures. For purposes of clearly defining the Network’s operating principles, the following
classifications are made:
Policies
Policies are high-level program statements that embrace the goals of the Network and define what is
acceptable to ensure success and effective, consistent program operations. Policies are crucial to
achieving the Network’s mission and goals and are developed for program practices that are mandatory
and non-negotiable in nature. Policies lower the risk of program failure and reduce the threat of legal
recourse. Policies may indicate who has authority for final decisions and broad consequence options for
non-compliance. Policies are approved and monitored by the MAT.
Procedures
Procedures are statements that describe how a particular operational function is to be implemented and
managed within the Network. Procedures are brief statements that describe the step-by-step process
necessary to implement and support the Network’s policies and practices. Procedures include descriptions
of who is responsible for each task. Procedures are governed by the MAT.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 1
Comparison of Policies and Procedures
Policies
Widespread application
Non-negotiable, changes infrequently
Expressed in broad terms and requirements
Statements of “what” and/or “why”
Answers major operational issue(s)
Approved by MAT
Procedures
Narrower focus
Open to change or continuous improvement
Detailed descriptions of activities
Statements of “how,” “when,” and/or “who” and
sometimes “what”
Describes process
Managed by the MAT and contract staff
How This Manual Is Organized
The purpose of this manual is to provide an overview of the Network’s policies and procedures. The
contents of this manual include all policies and procedures necessary to the successful operation of the
Network.
Chapter 1. Overview
This chapter provides general information about the importance of policies and procedures as well as an
overview of the structure of the manual.
Chapter 2. The Meteor Network
This chapter includes essential information about the Network. This information is important because it
helps to define and outline the core structure of the Network and the MAT.
Chapter 3. Network Policies
This chapter identifies core critical policies that the Network uses to administer the Network.
Chapter 4. Network Procedures
This chapter addresses the Network procedures that support and operationalize the Network policies.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 2
Chapter 2. THE METEOR™ NETWORK
The Meteor software provides a web-based universal access channel to student/borrower financial aid
information. The Meteor Software displays aggregated financial aid award information for FEELP and
alternative loans. Future implementations are planned to include Perkins loans, Federal Direct loans,
grants, scholarships and other financial aid awards. The current Meteor Network aggregates
student/borrower loan information for display to Financial Aid Professionals, students/borrowers, and
customer service professionals. Meteor Access Provider customer service representatives have the ability
to view data on student aid to which their organization is a party. The Meteor software is provided by the
FFELP industry as a gift to schools and students/ borrowers. The National Student Clearinghouse is
leading this effort as another collaboration of industry participants, to provide quality products to schools
and students/borrowers.
The objective of the Meteor Network is to provide accurate and comprehensive information to Financial
Aid Professionals to help them with counseling students/borrowers and assisting with the financial aid
process in general. The Meteor Network also provides accurate and comprehensive information to
students/borrowers to assist them in tracking their financial aid history. It is also designed to assist
customer service professionals at Access Provider locations with assisting Network users.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 3
Meteor Users
There are four types of user in the Meteor Network:

Students/Borrowers

Financial Aid Administrators

Customer Service Representatives

Lenders
Meteor users have varying levels of access to information provided within the Meteor Network. These
distinctions will be made throughout this guide, as appropriate.
Meteor Providers
Providers within the Meteor Network are broken down into four fundamental categories:
Providers, Data Providers, Authentication Agents and Index Providers.
Access
A Meteor Access Provider hosts a copy of the Meteor Access Provider software. Access providers can be
schools, guarantors, lenders, servicers, or secondary markets. After performing its own authentication of
the user making the inquiry, the Meteor Access Provider software generates a request to the appropriate
Data Providers for the student/borrower’s information. The software uses an index to identify the
location(s) of the requested student/borrower financial aid information and thereby creates efficiencies in
the request process.
A Meteor Data Provider hosts a copy of the Meteor Data Provider software that enables them to respond
to an Access Provider’s request for information. Data Providers are typically lenders, servicers,
guarantors, and secondary markets.
A Meteor Authentication Agent is an organization that creates an assertion attesting to the fact that a user
is who they claim to be. The Authentication Agent can be a school, guarantor, lender, servicer or other
organization that has a database of information on individuals sufficient to validate an end users identity.
A Meteor Index Provider hosts a copy of the Meteor Index Provider Software that allows them to identify
the Data Providers for which the Access Providers need to contact on a student-by-student basis. Because
there is no central database within Meteor, the Index Provider serves as the central source for information
on the location of a student’s financial aid information. The Meteor Network is designed to support
multiple Index Providers, as there is no single source of ALL financial aid information available in Higher
Education.
The Meteor Federation Model
The Meteor Network provides organizations with a federated authentication methodology. This enables
providers to easily implement enhanced web services without requiring bilateral agreements. The Meteor
Network providers agree to follow the policies and procedures of the Network. This results in multilateral
trust among all providers. The Meteor Network thereby builds a framework for widespread
authentication and identity management within the higher education community.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 4
The Meteor Network has created a set of business rules that define the minimum requirements for
participation and to address organizational liabilities. This information can be found in the Meteor
Participant Certification document.
A fundamental critical success factor in Meteor acceptance and for widespread adoption is the integrity of
the network. This means that Data Providers, Access Providers, students/borrowers, schools, and auditors
must be confident that Meteor meets reasonable requirements for data privacy and security. Accordingly,
Meteor has established the following security and privacy objectives:
• Comply with the Gramm-Leach-Bliley Act (GLBA), Department of Treasury interagency
guidelines, and other state enacted legislation and be able to pass an independent audit for Security
and Privacy;
• Assure Data Providers that reasonable authentication mechanisms are used so that only
authenticated inquirers have access to the network;
• Assure Data Providers that appropriate authority levels will be used to control what data an
inquirer is enabled to view, based on their role, authority, and relationship to the data (data
filtering);
• Perform the above with a minimum level of administrative overhead and intrusive requirements
for schools, students/borrowers, Access Providers and Data Providers; and
• Provide a flexible foundation for future Meteor enhancements that will allow additional
functions to be added without causing major changes in the authentication and privacy
infrastructure.
In order to meet these objectives, the Meteor effort developed an authentication model that is supported
by a number of industry standards. The following design principles are incorporated in this model:
• Digital Certificates will be used to authenticate Access Providers and Data Providers, and
• The OASIS SAML XML security standard is used. Internet 2 “Shibboleth” authentication
architecture was used as a model for Meteor technical standards. You can obtain more information
on Shibboleth at http://shibboleth.internet2.edu/
The Access Provider performs authentication of inquirers using their current login rules that establish the
initial level of authentication. Data Providers will be able to identify the authentication process used by
the Access Provider or Authentication Provider in the case of third party authentication through the
Meteor registry entry for that Access Provider or Authentication Provider.
• If the Data Provider requires a more stringent or “higher level” of authentication than the Access
Provider or Authentication Provider has performed, then the Data Provider may require that an
additional authentication request be solicited from the inquirer (e.g., Data Provider requires a
private password or PIN which is a more stringent or “higher level” of authentication than the
student/borrower name and date of birth authentication performed by the Access Provider or
Authentication Provider).
• If a higher level of authentication is obtained, then the entity providing that authentication must
sign the new authentication assertion and Data Providers will use that new higher level of
authentication instead of the initial level of authentication as a comparison against their required
level.
Electronic authentication (E-authentication) is the process of establishing confidence in user identities
electronically presented to an information system. The National Institute of Standards and Technology
(NIST) have published recommendations to provide technical guidance to allow an individual person to
remotely authenticate his/her identity to a Federal IT system, Electronic Authentication Guideline, [NIST
800-63]. This guidance addresses only traditional, widely implemented methods for remote authentication
based on secrets. With these methods, the individual to be authenticated proves that he or she knows or
possesses some secret information. NIST expects to explore other means of remote authentication (for
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 5
example using biometrics, or by extensive knowledge of private, but not truly secret, personal
information) and may develop additional guidance on the use of these methods for remote authentication.
The Meteor Advisory Team continually monitors state and Federal authentication standards to ensure that
the Network is in compliance with the latest trends in security and authentication.
This technical guidance supplements OMB guidance, E-Authentication Guidance for
Federal Agencies, [OMB 04-04], that defines four levels of authentication Levels 1 to 4, in terms of the
consequences of the authentication errors and misuse of credentials. Level 1 is the lowest assurance and
Level 4 is the highest. The OMB guidance defines the required level of authentication assurance in terms
of the likely consequences of an authentication error. As the consequences of an authentication error
become more serious, the required level of assurance increases. The OMB guidance provides Federal
agencies with the criteria for determining the level of e-authentication assurance required for specific
applications and transactions, based on the risks and their likelihood of occurrence of each application or
transaction.
The NIST recommendations state specific technical requirements for each of the four levels of assurance
in the following areas:
• tokens (typically a cryptographic key or password) for proving identity,
• identity proofing, registration and the delivery of credentials which bind an identity to a token,
• remote authentication mechanisms — that is, the combination of credentials, tokens and
authentication protocols used to establish that a claimant is in fact the subscriber he or she claims
to be, and
• assertion mechanisms used to communicate the results of a remote authentication to other parties.
NIST defines Level 1 authentication as authentication with no identity proofing requirements and
provides a low level of assurance that the user is who they claim to be. Plaintext passwords or secrets are
not transmitted across a network at Level 1
NIST defines Level 2 authentication as a model that provides single factor remote network authentication.
At Level 2, identity-proofing requirements are introduced, requiring presentation of identifying materials
or information. A wide range of available authentication technologies can be employed at Level 2. It
allows any of the token methods of Levels 3 or 4, as well as passwords and PINs. Successful
authentication requires that the claimant prove through a secure authentication protocol that he or she
controls the token. Eavesdropper, replay, and on-line guessing attacks are prevented.
Long-term shared authentication secrets, if used, are never revealed to any party except the claimant and
verifiers operated by the Credentials Service Provider (CSP); however, session (temporary) shared secrets
may be provided to independent verifiers by the CSP. Approved cryptographic techniques are required.
Assertions issued about claimants as a result of a successful authentication are either cryptographically
authenticated by relying parties (using Approved methods), or are obtained directly from a trusted party
via a secure authentication protocol.
The Meteor Network is compliant with the NIST Level Two authentication guidelines.
More detail regarding authentication is contained in Section 2, Technical Reference of the Meteor
Implementation Guide available at www.meteornetwork.org.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 6
Mission Statement
Meteor will be recognized and accepted as the standard for real time, secure
access to comprehensive, timely and accurate student financial aid information.
Vision Statement
Meteor will be THE standard means for accessing higher education data from
distributed sources.
Strategic Objectives
I.
Objective: Provide, through open collaborative participation, freely available open-source software
and support that enables low cost implementation.
II.
Objective: Provide the right data at the right time from the right source.
III.
Objective: Continue to be an open source product collaboratively developed by industry
participants, which embraces recognized and emerging technology standards to provide for quick
secure access to distributed data.
IV. Objective: Enable participants to provide their customers with real-time access to comprehensive
financial aid data anytime and anywhere.
V.
Objective: Secure all-inclusive implementation by data and access providers.
Critical Success Factors (CSF)
For each objective, we have identified specific critical success factors for meeting the objective.
I.
Objective: Provide, through open collaborative participation, freely available open-source
software and support that enables low cost implementation.
A. Sufficient high quality human resources to support and enhance Meteor must be consistently available.
B. MAT ensures evaluation of industry issues and perspectives.
C. Provide high quality technical support.
D. Sufficient financial resources to support the strategic objectives.
II.
Objective: Provide the right data at the right time from the right sources.
A. 100% of the FFELP data.
B. Ensure best source of data.
C. Ensure that data presentation meets the needs of the end users.
D. Provide access to state, federal, institutional financial aid and private loan data.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 7
III. Objective: Continue to be an open source product collaboratively developed by industry
participants, which embraces recognized and emerging technology standards to provide for
quick secure access to distributed data.
A. Sufficient high quality technical human resources to support and enhance Meteor must be consistently
available.
B. Provide a forum to research and implement emerging technologies.
C. Participate in industry standard setting initiatives.
D. Maintain/enhance software development and testing infrastructures.
E. Maintain the highest level of integrity and security.
F. Provide a version of the Meteor software for those participants whose organizations prohibit usage of
Open Source software.
IV. Objective: Enable participants to provide their customers with real-time access to
comprehensive financial aid data anytime and anywhere.
A. Provide end user documentation (e.g. online help and user guides are KPIs)
B. Provide network availability 24/7 and fast response time.
C. 100% of FFELP data.
D. Ensure timely reporting and updating to the index and registry.
E. Minimize implementation steps for access providers and data providers.
F. Limit number of releases per year and ensure they are backward compatible.
G. Continue to support a customizable look and feel.
H. Maintain and enhance participant support infrastructure.
I.
Ensure that data presentation meets the needs of the end users.
J. Conduct periodic end user surveys through the access provider.
V.
Objective: Secure all-inclusive implementation by data and access providers.
A. Schools should see the value in using Meteor to drive increased participation.
B. Meteor is seen as value added to existing services offered by organizations rather than a threat.
C. Meteor is viewed as a value added service to be provided by access providers and data providers to their
customers.
D. Meteor obtains safe harbor from DE.
E. Meteor members and participants must see a return on investment.
F. Maintain the highest level of integrity and security.
G. Meteor must build alliances with other industry organizations in order to gain industry acceptance.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 8
The Meteor Network
CHAPTER 3. METEOR™ NETWORK POLICIES
Meteor Advisory Team Participation Policy
It is the policy of the Meteor Network that membership on the Meteor Advisory Team (MAT) is limited
to individuals employed by Meteor Member organizations. There will be certain instances, however,
when specialized teams may need to be formed with participation outside of the MAT. In these instances,
the MAT will have responsibility to approve such requests.
Network Usage Policy
It is the policy of the Meteor Network that all users of the Network must be authenticated by an Access
Provider or Authentication Agent prior to being given access to data on the Network. Refer to the Meteor
Conditions of Use and the Meteor User Certification information contained in the Meteor Participant
Certification document.
The Access Provider or their Authentication Agent is responsible for ensuring that the end-user is eligible
to use the Network and for assigning and determining the role of the end-user. The Participant
organizations will support the project manager in these activities as required.
Access Provider Eligibility Policy
It is the policy of the Meteor Network that all Access Providers meet the requirements and agree to the
terms of the Meteor Participant Certification document.
The MAT assumes lead responsibility for the determination of eligibility for participation.
Data Provider Eligibility Policy
It is the policy of the Meteor Network that all Data Providers meet the requirements and agree to the
terms of the Meteor Participant Certification document.
The MAT assumes lead responsibility for the determination of eligibility for participation.
Authentication Agent Eligibility Policy
It is the policy of the Meteor Network that all Authentication Agents meet the requirements and agree to
the terms of the Meteor Authentication Agent Certification document.
The MAT assumes lead responsibility for the determination of eligibility for participation as an
Authentication Provider.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 9
Participant Privacy & Security Policy
It is the policy of the Meteor Network that all participants have established policies, procedures and
practices to protect against unauthorized access to, or use of, data received through their Meteor Network
connection. It is also the policy of the Meteor Network that participants agree to promptly report to the
MAT any individuals whom the Meteor Participant believes may be improperly obtaining data through
the Meteor Network. It is the policy of the Meteor Network that all participants meet and adhere to the
requirements set forth in the Meteor Participant Certification document.
The Meteor Participants certify their compliance with the participant privacy and security policy. The
MAT is responsible for the monitoring of participant compliance.
Removal from the Network Policy
It is the policy of the Meteor Network that a Meteor Participant may withdraw from participation in the
Network by providing at least thirty (30) days advance written notice to the MAT. Additionally, the
MAT may revoke participation in the Network without notice, in cases where the integrity of the Network
is at risk.
The project manager assumes lead responsibility for the coordination of removal of participants from the
Network under the direction of the MAT. The Participant organizations will support the project manager
in these activities as required.
Use of Data Policy
It is the policy of the Meteor Network that Meteor Participants shall not capture, store, use or reuse any
data obtained through the Meteor Network. This prohibition does not apply to postsecondary school
Participants so long as the use is in connection with the Participant’s official duties. Additionally, no
Meteor Participant shall use any data obtained through the Meteor Network for marketing and/or
solicitation purposes.
The Meteor Participants certify their compliance with the use of data policy. The MAT is responsible for
the monitoring of Participant compliance.
Use of Data Exception Approval Policy
It is the policy of the Meteor Network that a Meteor Participant shall be allowed to capture, store, use or
reuse any data obtained through the Meteor Network so long as the Participant demonstrates to the MAT
that it will only use the data for one of the purposes identified in the Meteor User Certification.
The MAT assumes lead responsibility for the granting of exceptions to the Use of Data policy.
Clearinghouse staff and Board of Directors will support the MAT in these activities as required.
Disaster Recovery Policy
It is the policy of the Meteor Network that all Network participants and providers have a disaster recovery
plan that identifies and mitigates against risks to critical systems and sensitive information in the event of
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 10
a disaster. These plans shall provide for contingencies to restore information and systems if a disaster
occurs.
The MAT assumes lead responsibility for ensuring that all participants and providers have sufficient plans
in place.
Dispute Resolution Policy
It is the policy of the Meteor Network that, should disputes regarding Network services or the use of those
services arise among Participants or between a Participant and the Network, the participants should follow
the appropriate procedures for resolving the dispute.
Upon resolution, a brief description of the dispute issues and the resolution of those will be posted to the
members-only section of the Meteor website.
The MAT assumes lead responsibility for dispute resolution. Clearinghouse staff and Board of Directors
will support the MAT in these activities as required.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 11
CHAPTER 4. METEOR™ NETWORK PROCEDURES
Meteor Registration Process – Access Providers
Purpose
Process
The purpose of this procedure is to outline the registration process for a
potential Meteor Access Provider.
The following table outlines the registration process for a potential Meteor
Access Provider.
Step
1
2
3
4
Action
Potential Access Provider (AP) contacts Meteor Registration
Coordinator (MRC) at meteor@studentclearinghouse.org
Potential AP should obtain the following from the MRC:
• Meteor Participant Certification
• Registration Profile
• Authentication Profile(s)
• Technical Profile
Potential AP should complete all forms from Step 2.
Potential AP submits completed forms, along with a copy of their
Authentication Policy to the MRC at:
Meteor Registration Coordinator
c/o The National Student Clearinghouse
2300 Dulles Station Blvd, Suite 300
Herndon, VA 20171
5
6
7
8
9
10
11
Note: If AP is using an Authentication Agent, then they must
submit the name of the agent as well as the Authentication Policy
of that agent. The AP does not need to complete the
Authentication Profile, but must submit an Authentication Profile
for its agent.
MRC emails completed forms and Authentication Policy to the
Meteor Team Leads.
The Meteor Team Leads review the documents and assigns
appropriate authentication level.
The MRC contacts the Meteor registry host to designate the
potential AP as “active” in the test registry and to update the
authentication level of the provider.
The MRC contacts the potential AP and advises them to contact
the Meteor Index Provider, the National Student Clearinghouse
(Clearinghouse), to begin connectivity testing.
Potential AP contacts the MRC upon successful completion of
testing.
The MRC contacts the Meteor registry host to designate the new
AP as “active” in the production registry.
The MRC coordinates all announcements and press releases with
the new AP.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 12
12
13
The MRC updates the following:
• The Meteor website with new AP as an active participant
• The Meteor business production listserv with AP’s primary
business contact
• The Meteor technical production listserv with AP’s primary
technical contact
Process ends
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 13
Meteor Registration Process – Data Providers
Purpose
Process
The purpose of this procedure is to outline the registration process for a
potential Meteor Data Provider.
The following table outlines the registration process for a potential Meteor
Data Provider.
Step
1
2
3
4
Action
Potential Access Provider (DP) contacts Meteor Registration
Coordinator (MRC) at meteor@studentclearinghouse.org
Potential DP should obtain the following from the MRC:
• Meteor Participant Certification
• Registration Profile
• Technical Profile
Potential DP should complete all forms from Step 2.
Potential DP submits completed forms to the MRC at:
Meteor Registration Coordinator
c/o The National Student Clearinghouse
2300 Dulles Station Blvd, Suite 300
Herndon, VA 20171
5
6
7
8
9
10
11
12
13
MRC emails completed forms to the Meteor Team Leads.
The Meteor Team Leads review the documents.
The MRC contacts the Meteor registry host to designate the
potential DP as “active” in the test registry as well as the
appropriate minimum authentication level accepted. Any other
pertinent information should also be updated in the registry at this
time.
The MRC contacts the potential DP and advises them to contact
the Meteor Index Provider, the National Student Clearinghouse
(Clearinghouse), to begin connectivity testing.
Potential DP contacts the MRC upon successful completion of
testing.
The MRC contacts the Meteor registry host to designate the new
DP as “active” in the production registry.
The MRC coordinates all announcements and press releases with
the new DP.
The MRC updates the following:
• The Meteor website with new DP as an active participant
• The Meteor business production listserv with DP’s primary
business contact
• The Meteor technical production listserv with DP’s primary
technical contact
Process ends
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 14
Meteor Registration Process – Authentication Agents
Purpose
Process
The purpose of this procedure is to outline the registration process for a
potential Meteor Authentication Agent.
The following table outlines the registration process for a potential Meteor
Authentication Agent.
Step
1
2
3
4
Action
Potential Authentication Agent (AA) contacts Meteor Registration
Coordinator (MRC) at meteor@studentclearinghouse.org
Potential AA should obtain the following from the MRC:
• Authentication Agent Certification
• Registration Profile
• Authentication Profile(s)
• Technical Profile
Potential AA should complete all forms from Step 2.
Potential AA submits completed forms, along with a copy of their
Authentication Policy to the MRC at:
Meteor Registration Coordinator
c/o The National Student Clearinghouse
2300 Dulles Station Blvd, Suite 300
Herndon, VA 20171
5
6
7
8
9
10
11
12
13
MRC emails completed forms and Authentication Policy to the
Meteor Team Leads.
The Meteor Team Leads review the documents and assigns
appropriate authentication level.
The MRC contacts the Meteor registry host to designate the
potential AA as “active” in the test registry and to update the
authentication level of the provider. Any other pertinent
information should also be updated in the registry at this time.
The MRC contacts the potential AA and advises them to complete
testing with their Access Providers.
Potential AA contacts the MRC upon successful completion of
testing.
The MRC contacts the Meteor registry host to designate the new
AA as “active” in the production registry.
The MRC coordinates all announcements and press releases with
the new AA.
The MRC updates the following:
• The Meteor website with new AA as an active participant
• The Meteor business production listserv with AA’s primary
business contact
• The Meteor technical production listserv with AA’s primary
technical contact
Process ends
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 15
New Participant Review Procedure
Purpose
Process
The purpose of this procedure is to outline the review process for prospective
new participants.
The following table outlines the review process for new participants
Step
1
2
3
4
5
Action
The Meteor Advisory Team (MAT) Teams Leads receive a new
participant certification request from an organization
MAT Team Leads assess the following regarding the organization:
• Are they a member of the community
• Purpose of their participation
• Intended use of the data
• Assigned OPEID – If the participant does not have an
OPEID or a NCEHLP assigned id, the registration
coordinator will work with NCHELP to obtain a NCHELP
assigned id for the participant.
MAT Team leads review whether or not a customized display is
requested, if so, the MAT team leads will follow the Use of Data
Exception Procedure.
If all of the above are found to comply with Meteor policy the
registration process continues as per the participation role(s)
requested (Access Provider, Data Provider, and/or Authentication
Agent).
If any of the above does not to comply with Meteor policy, the
organization is notified by the registration coordinator that the
request is denied with an explanation of the reason for denial.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 16
Authentication Level Setting Procedure
Purpose
Process
The purpose of this procedure is to outline the review process for determining
the appropriate authentication level to be assigned to the Access Provider or
Authentication Agent.
The following table outlines the review process for new participants.
Step
1
2
3
4
5
6
7
Action
The Meteor Access Provider or Authentication Agent should
submit the Authentication Profile along with a detailed explanation
of how their authentication process works to the Meteor
registration coordinator.
The Meteor registration coordinator reviews the documentation for
completeness.
If complete, the registration coordinator disseminates the
documentation to each of the team leads
Independently, each team lead reviews the documentation and
assigns an authentication level (Refer to the Meteor
Implementation Guide for a description of each level of
authentication supported in the Meteor Network). Each reviewer
forwards their determination to the registration coordinator
If anyone determines there is not sufficient information to make an
authentication determination the lead will inform the registration
coordinator of the type of additional information need from the
participant
If all leads assign the same level of authentication, the
authentication level is set to that level;
If all leads do not assign the same level, the registration
coordinator will schedule a conference call for the leads to discuss
the respective level assignments and to work toward building
consensus on the level of authentication to be assigned.
Notification – The Meteor registration coordinator will notify the
participant of the level assigned.
The meteor registration coordinator will then follow the new
registry procedures to complete the process.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 17
Production Problem Reporting and Resolution Procedure
Purpose
Process
The purpose of this procedure is to identify the troubleshooting procedures as
well as the production problem reporting and resolution procedures.
The following table outlines the process for reporting and resolving
production problems.
Step
1
2
3
4
5
6
7
8
9
10
Action
A Meteor access or data provider identifies a potential problem
with the performance of the Meteor software.
IT resources from the access or data provider determine if the
organizations servers and applications are performing correctly.
Access or Data Provider IT resource verifies that Meteor is
successfully connecting to their systems.
If the Access or Data Provider determines their servers,
applications and connections are functioning properly, the Access
or Data Provider IT resource sends an email and any supporting
documentation to the Meteor help desk.
The Meteor helpdesk will run through a series of trouble shooting
activities to try and isolate the problem.
If the Meteor helpdesk cannot determine the cause of the problem,
the helpdesk staff will contact the Meteor developer for assistance.
If a problem is identified with the provider, the Meteor help desk
contacts the provider to inform them of the problem and
recommended actions that will be required to resolve the problem.
If a software problem is identified, the Meteor helpdesk will open a
problem ticket.
If a network problem is identified, the helpdesk will open a
problem ticket. If the problem is affecting the entire network, the
helpdesk will send an email to both the Meteor business and
technical production listserves with a cc: to the MAT and MAT
tech-team listserves.
Problem tickets will be reviewed by the MAT and the Meteor
developer to determine possible solutions to the problem reported.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 18
Code Donation Review and Distribution Procedures
Purpose
Process
The purpose of these procedures is to outline the process for the review,
acceptance and distribution of any code donated to the Meteor project.
The following table outlines the process for the review, acceptance and
distribution of the donated code.
Step
1
2
3
4
5
6
7
8
9
10
11
Action
Determine if the code donation is an enhancement to the current
production code or if it fixes a bug in the current version or in a
previous version.
If the code donation is an enhancement, the functionality must be
reviewed and approved by the MAT. The change and the approval
must be documented as a use case or issue paper and recorded in
the Meteor documentation site.
If the code donation fixes a bug, the donating organization must
document the problem and how it was resolved tying the
documentation back to the bugtraq numbers. It is recommended
that the donating organization also include the xml (or the
information that is triggering the condition) for test cases when
available.
Donating organization coordinates with the MAT Technical Team
Lead to have the code and change log posted to the Meteor
Technical Sharepoint site.
Business/Technical team reviews the problem reported and the
solution created and makes a determination on the impact of the
bug, the change, and how and when the revised code will be
implemented.
Donating organization walks through the code changes with the
business team, the tech team and the Meteor project developer.
Tech team and Meteor project developer review the changes made
[,] to validate that the code modifications correct the problem
reported and does not impact the code in any other way.
MAT determines if the donated code is acceptable as submitted or
if additional changes should be made. If the donated code is
acceptable, the MAT authorizes the Meteor project developer to
incorporate the changes into a new build of the software.
The MAT determines the testing requirements and sequence.
Business team builds test cases as appropriate.
Technical team builds test cases as appropriate.
Business and technical testing of the Meteor code.
Upon successful completion of testing, user documentation is
revised as appropriate, notification to organizations currently in
production, development, and/or testing is delivered, and the
implementation-tracking matrix is updated as appropriate.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 19
APCSR Alias List Review Procedure
Purpose
Process
The purpose of this procedure is to outline the process for the review and
maintenance of the APCSR alias lists.
The following table outlines the process for the review and updating of the
Meteor registry in support of the APCSR alias lists.
Adding, deleting or changing the status of registry records:
Step
1
2
3
4
5
6
7
Action
APCSR Access Provider submits a registration profile form which
lists the OPEID’s for which their customer service staff is eligible
to view information. The profile must be returned along with the
certification that a contractual agreement between the APCSR AP
and the owner(s) of the data to which access will be granted is in
place.
The Meteor registration coordinator reviews the organization
OPEID’s and/or NCHELP issued data exchange ids, and the
profile document.
The Meteor registration coordinator verifies the codes are valid
codes.
The Meteor registration coordinator contacts the data owner(s) to
confirm access to the APCSR Access Provider and provides them
with an APCSR Acknowledgement Form for signature.
Data owner(s) review, sign, and return Acknowledgement Form to
the Meteor registration coordinator.
If approved, the Meteor registration coordinator forwards the alias
list(s) to the Meteor registry host for inclusion in the central
registry.
If not approved, the Meteor registration coordinator responds back
to the Access Provider with an explanation. At this point, the
Access Provider may submit additional documentation to bring the
code to approval.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 20
Meteor Registry Change Procedures
Purpose
Process
The purpose of this procedure is to outline the process for changing the
production registry for a Meteor provider.
The following tables outlines the process:
Adding, deleting or changing the status of registry records:
Step
1
2
3
4
5
6
7
Action
Meteor Provider contacts Meteor Registration Coordinator (MRC)
at meteor@studentclearinghouse.org
Meteor Registration Coordinator confirms the change with the
Meteor Team Leads.
Meteor Registration Coordinator approves the change and sends
the provider data to the Meteor Help Desk at
meteorhelpdesk@studentclearinghouse.org.
The Meteor Help Desk makes the change and emails notification to
the Meteor Registration Coordinator that the change has been
made.
The Meteor Help Desk will connect to the failover registry
provider to ensure that any changes propagate successfully to the
replicated registry.
If changes do not propagate successfully, the Meteor Help Desk
will work with the failover registry provider to ensure successful
replication.
Process ends.
Updating public key data for existing registry records:
Step
1
2
3
4
5
6
7
Action
Meteor Provider emails their new public key to the Meteor Help
Desk at meteorhelpdesk@studentclearinghouse.org.
Meteor Help Desk contacts the Meteor Provider and verifies the
fingerprint of the key.
Meteor Help Desk deletes the previous key and adds the new key to
the provider’s registry record(s).
The Meteor Help Desk notifies the provider that the change has
been made.
The Meteor Help Desk will connect to the failover registry provider
to ensure that any changes propagate successfully to the replicated
registry.
If changes do not propagate successfully, the Meteor Help Desk
will work with the failover registry provider to ensure successful
replication.
Process ends.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 21
Updating contact information for existing registry records:
Step
1
3
4
5
6
7
Action
Meteor Provider emails their new contact information to the Meteor
Help Desk at meteorhelpdesk@studentclearinghouse.org.
Meteor Help Desk updates the provider’s registry record(s).
The Meteor Help Desk notifies the provider and the Meteor
Registration Coordinator that the change has been made.
The Meteor Help Desk will connect to the failover registry provider
to ensure that any changes propagate successfully to the replicated
registry.
If changes do not propagate successfully, the Meteor Help Desk
will work with the failover registry provider to ensure successful
replication.
Process ends.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 22
Removal from the Network Procedure
Purpose
Process
The purpose of this procedure is to outline the process for removing an
existing member from the Meteor Network. This procedure will outline two
distinct types of removals — voluntary and involuntary. A voluntary removal
will be when a member needs to stop participating for some reason. An
involuntary removal will be when a member must be removed to protect the
Meteor Network.
The process is outlined in the following steps:
Step
1
2
3
4
1
2
3
4
5
6
Action
Voluntary Removal:
Member notifies Meteor Project Manager at least 30 days prior to
requested removal date that they intend to discontinue participation
in the Meteor Network. A date and time are agreed to.
The Meteor project manager notifies all Meteor members via the
email groups, of the member’s request and expected date and time
to depart.
Project Manager schedules the removal from the Meteor Registry
with the Registry Host.
Project Manager works with Registry host to assure and test the
removal takes place as planned.
Involuntary Removal:
Meteor receives notification of a breach of agreement or other
security problem pertaining to a Meteor member.
Project Manager is immediately notified.
Project Manager makes determination to remove the offending
member. They may have discussions with other members and/or
offending member.
Project Manager notifies Registry Host to remove the offending
member from the Meteor Registry ASAP.
Project Manager works with the registry host to test to ensure the
offender was removed.
Project Manager notifies Meteor Network via email groups.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 23
Use of Data Exception Procedure
Purpose
Process
The purpose of this procedure is to outline the review process for allowing
and exception to the data use policy.
The following table outlines the review process for exceptions to the data use
policy:
Step
1
2
3
4
5
6
Action
The Meteor Project Manager or the Meteor Advisory Team (MAT)
Team Leads receives a request for an exception to the data use
policy.
MAT Team Leads assess the following regarding the request:
• Purpose of their participation
• Intended use of the data
MAT Team Leads review whether or not a Customized display is
requested or not?
• If not, ok.
• If yes, collaborative approach on development with MAT
If the use exception is approved, the Meteor Project Manager will
inform the participant the request is approved.
If the use exception is not approved, the Meteor Project Manager
will inform the participant the request has been denied.
The Meteor Project Manager and Clearinghouse legal counsel will
review any requests that are proprietary.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 24
Source Code Change Procedure
Purpose
Process
The purpose of this procedure is to outline the approval process for source
code changes.
The following table outlines the approval process for source code changes:
Step
1
2
3
4
5
Action
Business requirements are developed by the Meteor Advisory
Team in conjunction with the Meteor Software Developer.
The business requirements will be documented by the Meteor
Software Developer, reviewed and refined accordingly by the
MAT.
A formal signoff on the requirements document will be required by
the Meteor Project Manager, MAT Business Team Lead and the
Meteor Software Developer prior to the code phase beginning.
The signoff phase will include a development estimate by the
Meteor Software Developer.
Coding phase, unit testing and automated regression testing
Upon completion of the unit testing and auto regression a build
will be available for business team and tech team testing.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 25
Security Breach Reporting Procedure
Purpose
Process
The purpose of this procedure is to outline the process for Meteor participants
to report security breaches and what action will be taken by the Meteor team.
The following table outlines the process for Meteor participants to report a
security breach and the appropriate actions to be taken by the Meteor team.
Step
1
2
3
4
5
6
7
Action
Upon identification of a material breach, any Meteor participant
must promptly report the breach to the Meteor Help Desk and
terminate their connectivity to the network immediately.
The Meteor Help Desk will de-activate the Meteor participant in
the Meteor registry – production and failover.
The Meteor Help desk notifies MAT team leads and project
manager.
The MAT team leads and project manager will review and assess
the situation and communicate to network participants as
necessary.
Depending on the severity of the breach, if the MAT team leads
determine that the Network should be shut down, appropriate steps
will be taken to shut down the production registry and index as
well as the failover environments. The Meteor project manager
will communicate as necessary to organizations in production.
The MAT will work with the provider to correct the breach and
restore connectivity.
The MAT team leads and project manager will communicate
updates to the Network participants as necessary.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 26
Dispute Resolution Procedure
Purpose
Process
The purpose of this procedure is to outline the dispute resolution process
between participants and among participants and the Network.
The following table outlines the dispute resolution process for Meteor
Network participants.
NOTE: This procedure will evolve as the MAT gains more experience with the types of disputes that may
occur.
Step
1
2
3
4
5
6
1
2
3
4
5
6
Action
Disputes Among Participants
Participants should make every reasonable effort to settle disputes
among themselves, especially if contractual issues are involved. .
However, if circumstances warrant, then the Meteor team leads
may be asked to act as arbitrator in helping the participants come
to resolution.
The Meteor project manager will gather as much information as
possible from each disputing party and share this information with
the Meteor team leads.
The team leads and project manager will hold a conference call to
review the information (requesting additional information as
necessary).
The Meteor project manager will offer the proposed solution to the
disputing parties.
If this process fails to bring consensus among the participants, then
the dispute should be escalated to a dispute between participants
and the Network. (See process below.)
If this process brings consensus among the participants, the
participants will take the appropriate steps to implement the
solution.
Disputes Between Participants and the Network
Any participant may submit a written request to the Meteor project
manager with regard to aspect of the operation or services
supported by the Network.
The project manager will validate that sufficient information has
been provided to define the dispute and will notify the MAT team
leads.
The team leads will appoint one of the members to serve as the
mediator with the disputing party(s).
The mediator will collect all the facts and rationales for the dispute
and, as necessary, seek advice from other relevant parties.
The mediator will prepare a report which will include a
recommended resolution of the dispute. The report shall be
submitted to the project manager within 30 days unless delayed
due to fact-finding requirements.
The project manager will share the report with the team leads. The
team leads may require additional information or a modified
recommendation after reviewing the report.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 27
7
8
Resolution of the dispute must be approved by affirmative vote of
the team leads. If the team leads are unable to affirm a resolution,
the status quo is maintained.
The project manager shall report the team lead’s action to the
disputing party(s) in writing.
.
Copyright © 2011, National Student Clearinghouse – Policy and Procedure Manual – May 2011
Page 28
BPMN Grading Rubric | BMIS603_D01_202320
Criteria
Process
Prospectus
Process
Diagram
Ratings
Points
30 to >27 pts
27 to >24 pts
24 to >0 pts
0 pts
Advanced
Proficient
Developing
Not Present
Identifies all the major
processes with precession
and accuracy.
Each process is well defined,
detailed, supported, and
aligns with current industry
best practices consistent with
relevant literature.
Identifies all the
major processes with
at least 70%90% precession and
accuracy and/or
70%- 90% of the
processes are
defined, detailed,
supported, and align
with
current industry best
practices consistent
with relevant
literature.
Identifies all the
Substantially
major processes with unmet or not
less than 70%
present
precession and
accuracy and/or less
than
70% of the
processes are
defined, detailed,
supported,
and align with
current industry best
practices consistent
with relevant
literature.
40 to >36 pts
36 to >33 pts
33 to >0 pts
0 pts
Advanced
Proficient
Developing
Not Present
Comprehensive identification
of all major business
processes and auxiliary
processes. Uses BPMN
in a manner consistent with
the most current BPMN
standards per scholarly
literature.
Diagrams show the activities
within the process in the
proper
sequence and with granular
level of detail. All the decision
points in the process are
represented accurately in the
diagram.
Modern best practices in
BPMN modeling are present
throughout the diagrams
Identification of all
major business
processes and
auxiliary processes.
Uses BPMN in a
manner consistent
with
current BPMN
standards per
scholarly literature.
70%-90% of the
diagrams show the
activities within the
process in the proper
sequence and with
granular level of
detail. 70%90% of the decision
points in the process
are represented
accurately in the
diagram.
Modern best
practices in BPMN
modeling are present
throughout the
diagrams.
Identification of all
major business
processes and
auxiliary processes.
Uses BPMN in a
manner consistent
with current
BPMN standards per
scholarly literature.
Less than 70% of the
diagrams show the
activities
within the process in
the proper
sequence and with
granular level
of detail and/or less
than 70% of the
decision points in the
process are
represented
accurately in the
diagram.
Substantially
unmet or
correct
diagrams
and/or
diagram
screenshots
are not
included to
show the
processes
were
completed
by the
student.
30 pts
40 pts
BPMN Grading Rubric | BMIS603_D01_202320
Criteria
Ratings
Process
40 to >36 pts
Reengineering
Diagram
Advanced
36 to >33 pts
33 to >0 pts
0 pts
Proficient
Developing
Not Present
70%-90% of reengineering diagrams
are optimal and
follow current
industry best
practices as
supported by
scholarly journal
articles and/or
70%-90% of costs
are accurate and
detailed with proper
financial analysis
formulas and line
item spreadsheets
and/or
70%-90% of benefits
and risks are
accurate and
thoroughly detailed.
Less than 70% of
re-engineering
diagrams areoptimal
and follow
current industry best
practices as
supported by
scholarly journal
articles and/or less
than 70% of costs
are accurate and
detailed with proper
financial analysis
formulas and line
item
spreadsheets and/or
less than
70% of benefits and
risks are accurate
and thoroughly
detailed
Substantially
unmet or
correct
diagrams
and/or
diagram
screenshots
are not
included to
show the
processes
were
completed
by
the student
30 to >27 pts
27 to >24 pts
24 to >0 pts
0 pts
Advanced
Proficient
Developing
Not Present
Process evaluation accurately
details the entire process, is
granular in detail, and
supports the purpose of the
reengineering models with
current and scholarly journal
articles and industry best
practices.
Process evaluation
accurately details
70%-90% of the
process, is granular
in detail, and/or
mostly supportsthe
purpose of the
reengineering models
with
current and scholarly
journal articles and
industry best
practices.
Process evaluation
details less than
70% of the process,
is
granular in detail,
and/or does not
adequately support
the
purpose of the
reengineering
models with current
and
scholarly journal
articles and industry
best practices.
Substantially
unmet or
inaccurate
Re-engineering diagrams are
optimal and follow current
industry best practices as
supported by scholarly journal
articles. Costs are accurate
and detailed with proper
financial analysis formulas
and line item spreadsheets.
Benefits and risks are
accurate and thoroughly
detailed.
Process
Evaluation
Points
40 pts
30 pts
BPMN Grading Rubric | BMIS603_D01_202320
Criteria
Ratings
APA,
20 to >18 pts
Grammar, and
Spelling
Advanced
Properly formatted APA paper
with table of contents and
references pages. Correct
spelling and grammar used.
Contains fewer than 2 errors
in grammar or spelling that
distract the reader from the
content and/or minimal errors
(1-2)
noted in the interpretation or
execution of proper APA
format.
Excellent organization,
headings, and flow of the
main concepts exist.
Points
18 to >16 pts
16 to >0 pts
0 pts
Proficient
Developing
Not Present
Paper contains fewer
than 5
errors in grammar or
spelling that distract
the reader from
the content and/or
some errors
(3-7) noted in the
interpretation or
execution of
proper APA format
and/or
inadequate
organization,
headings, and flow of
the main
concepts exist and/or
notable absences in
required APA
formatting elements
such as:
Title page, running
head font type and
size (Times New
Roman 12 point), line
spacing, headings,
organization of
concepts, and flow of
the main ideas.
Paper contains fewer Substantially
than 10 errors in
unmet or not
grammar or spelling present
that distract the
reader from the
content and/or
numerous errors
(7+) noted in the
interpretation or
execution of proper
APA
format and/or
inadequate
organization,
headings, and flow
of the main concepts
exist
and/or notable
absences in required
APA formatting
elements such as:
Title page,
running head font
type and size
(Times New Roman
12 point), line
spacing, headings,
organization of
concepts, and flow of
the main ideas
20 pts
BPMN Grading Rubric | BMIS603_D01_202320
Criteria
Requirements
Ratings
Points
40 to >36 pts
36 to >3 pts
3 to >0 pts
0 pts
Advanced
Proficient
Developing
Not Present
Over 3,000 words exist of
original student authorship
that shows excellent mastery
and
knowledge of BPMN
processes,
modeling, and design
diagrams. Over 18 unique
scholarly peer reviewed
journal articles from
well-respected IT journals
exist that directly relate to and
3,000 words exist of
original student
authorship that
shows
knowledge of BPMN
processes,
modeling, and design
diagrams and/or less
than 18 unique
scholarly peer
reviewed journal
articles from
well-respected IT
journals exist that
directly relate to and
sufficiently
support the working
designs and
processes.
Less than 3,000
words exist of
original student
authorship that
shows knowledge of
BPMN
processes,
modeling, and
design diagrams
and/or less than 18
unique scholarly
peer reviewed
journal articles from
well respected IT journals
exist that
directly relate to and
sufficiently
support the working
designs and
processes
Substantially
unmet or not
present
and/or
irrelevant
sufficiently support the
working designs and
processes.
40 pts
Total Points: 200

Purchase answer to see full
attachment

We offer the bestcustom writing paper services. We have done this question before, we can also do it for you.

Why Choose Us

  • 100% non-plagiarized Papers
  • 24/7 /365 Service Available
  • Affordable Prices
  • Any Paper, Urgency, and Subject
  • Will complete your papers in 6 hours
  • On-time Delivery
  • Money-back and Privacy guarantees
  • Unlimited Amendments upon request
  • Satisfaction guarantee

How it Works

  • Click on the “Place Order” tab at the top menu or “Order Now” icon at the bottom and a new page will appear with an order form to be filled.
  • Fill in your paper’s requirements in the "PAPER DETAILS" section.
  • Fill in your paper’s academic level, deadline, and the required number of pages from the drop-down menus.
  • Click “CREATE ACCOUNT & SIGN IN” to enter your registration details and get an account with us for record-keeping and then, click on “PROCEED TO CHECKOUT” at the bottom of the page.
  • From there, the payment sections will show, follow the guided payment process and your order will be available for our writing team to work on it.