var gwr=document.getElementById('graphWithRefs0'); gwr.style.display='block'; gwr.scrollLeft=this.scrollLeft; this.style.display='none';
var gwr=document.getElementById('graphWithRefs0'); gwr.style.display='block'; gwr.scrollLeft=this.scrollLeft; this.style.display='none';
var gwor=document.getElementById('graphWithoutRefs0'); gwor.style.display='block'; gwor.scrollLeft=this.scrollLeft;this.style.display='none';
var gwor=document.getElementById('graphWithoutRefs0'); gwor.style.display='block'; gwor.scrollLeft=this.scrollLeft;this.style.display='none';
Module Statistics:
|
All clafers: 142 | Abstract: 23 | Concrete: 119 | Reference: 46 | Constraints: 73 | Goals: 0 | Global scope: 1..* | Can skip name resolver: no
|
A Merchandise Financial Planning (MFP) system deals with three main
types of hierarchies; Calendar, Product, and Location.
Calendar Hierarchy– represents the time units that
the system deals with, such as Season, Month, and Week for the Spring
2004 season.
Product Hierarchy– represents the several product
categories that the system deals with, such as department, class, and
sub-class for Men’s Casual Wear, or Men’s Formal Wear in Fashion
store.
Location Hierarchy– reflects multiple channels
within the organization at their aggregate level, such as total Brick
and Mortar Divisions, catalog and/or e-commerce.
MFP systems have the concept of workflows or workbooks which they use
to manage and complete their entire plan.
Users may edit data at different levels of each hierarchy (product,
location, and calendar). A hierarchy level can spread to one or more
lower related levels within the same hierarchy, or aggregates to one or
more higher levels within the same hierarchy.
In order to ensure that related level belongs to the same hierarchy
type, we introduce the concept of Hierarchy Level Instance. For
instance, a “Year” level in the “Calendar” Hierarchy spreads to “Month”,
“Week”, and “Days” levels. However, it can’t spread to the “department”
level for the “Product” hierarchy.
The strategic and financial planning processes are supported by
different plan versions to designate different plan types. These version
names and their abbreviations are used frequently; for example, in views
to distinguish measures.
The different plan versions, and their corresponding abbreviations
include:
Working Plan (Wp), Original Plan (Op), Current Plan (Cp), Last Year
Plan (Ly), Target
Plan (Tgt), Waiting for Approval Plan (Wa) Each plan is created by
one or more planning role(s), and belongs to a specific retail channel
such as store or a catalog.
enum VersionAbbreviation = Op | Cp | Wp | Ly | Wa | Tgt
Requirement #29: When seeding a plan, you choose which information
to seed. You can seed a certain level of each hierarchy (product,
calendar, location) or all levels.
The original plan is a plan version which acts as the baseline
against which the current plan is evaluated. It is pre-Season plan that
has been approved and promoted from (Wa) to (Op). All roles can view the
Op version measures.
Requirement #3: The planning processes are supported by key financial
indicators (metrics) that include sales, markdown, turn, receipts,
inventory, gross margin, and open-to-buy.
Requirement #31: MFP users can plan sales based on three
classifications; regular, promotional and clearance sale.
Requirement #32: Markdowns are classified into regular, promotional
and permanent markdowns.
Requirement #4: There are three types of planning roles in MFPs;
Top-down, Middle-out, and Bottom-up.
Requirement #5: Top-down roles are typically planning directors. They
create the overall targets for the company and set top-down group level
targets for the middle out role.
Requirement #6: Middle-out roles are typically planning managers. They
create middle-out targets.
Requirement #7: Bottom-up roles are typically merchandise planners.
They create Op (Original Plan) and Cp (Current Plan) plans for approval
by the middle out role.
Requirement #8: The targets are published by superior levels to the
subsequent level: top down passes to middle out, and middle out passes
to bottom up. The bottom up then submits the Op, Cp, or both to the
middle out role for approval.
These are the lower level components from which the target plan is
composed. As previously mentioned, the targets are either created by
TopDown or MiddleOut roles, and published to lower levels.
Requirement #12: MFPs follow workflows for creating/managing plans,
and each workflow has one or more views.
Requirement #1: The planning processes is divided into two-sub
processes; Creating the merchandise financial plan which occurs during
pre-season planning. Managing and updating the merchandise financial
plan occurs during in-season planning.
Requirement #2: Pre-season planning focuses on creating the original
plan against which to benchmark the in-season progress after being
approved.
Requirement #23: If you are doing pre-season planning, then it can’t
be proceeded by in-season planning.
Requirement #24: Once you are in-season planning, you can’t return to
the pre-season planning stage.
Requirement #13: There are views who are meant to be seen by a single
specific role, and others that could be seen by all roles.
Requirement #14: Each view has one or more measures.
Requirement #15: The strategic and financial planning processes
supported by MFP use plan versions to designate different plan types
that are used throughout the planning horizon. These version names and
their abbreviations are used frequently in planning views (for example,
to distinguish measures).
Requirement #30: Top-Down roles are not involved in in-season
planning, only Middle-out and Bottom-up roles.
Requirement #33: In the view, you choose to seed, approve, create, or
review a plan.
2.16. Measure Requirement #17: Each measure could be expressed either
in $ amount or as a percentage called unit of measure (UOM).
Requirement #18: A measure is defined for a specific metric, UOM, and
a plan version it belongs to.
Requirement #19: Measures are classified into reference and
non-reference measures (historical ones).
Requirement #20: All measures are visible by all roles.
Requirement #21: A non-reference measure is meant to be edited by a
specific role.
Requirement #22: Reference measures can’t be edited by any role.
Requirement #25: Measures could be derived by other measures, be used
to derive other measures, could have both previous properties, or a
regular measure (i.e. isn’t any of the mentioned)
The rule is dealt with here in a superficial manner. It had to be
present since a “Measure” derives or is derived by another measure
through some rule. The details of those rules are outside the scope of
the model.
