Crew Manager - Attribute Use Case Examples

Example 1

In this example, we will consider whether ‘members’ meet EITHER one or BOTH of two different criteria.
We will be evaluating 2 member-level attributes. Keep in mind that this example could be expanded to
evaluate members against more than 2 criteria.

Let’s determine how many members:
• Are Lineman?
AND/OR
• Are Working?

We can easily look at EITHER criteria using existing attributes.The Attribute, Prim_Class, will tell us if the member is a Lineman.
The Attribute, Status, will tell us if the member is Working.

We could summarize Prim_Class or Status and see how many members are Linemen or how many are
Working. But to evaluate members against both criteria, we need to use a different approach.

Let’s think in terms of combining traits (the criteria, Prim_Class and Status) into a “code” that will
identify the members that meet either criteria. Each criteria can be evaluated to return Y or N. The
“code” created will be a 2-character identifier, because there are 2 criteria, as explained below.

Is Lineman?	Is Working?	"Code"
A member can be a Lineman (Yes)	but not Working (No)	YN
A member can be a Lineman (Yes)	and be Working (Yes)	YY
A member can be not a Lineman (No)	and not be Working (No)	NN
A member can be not a Lineman (No)	but be Working (Yes)	NY

To create the attribute that holds the “code” we must FIRST ‘translate’ text values for each separate
criteria (attribute) into Y or N values.

Let’s start with the Prim_Class attribute.
This attribute could contain any number of values, but the one we are interested in is Lineman. So, we
create a new attribute that uses the contains formula to look at the Prim_Class attribute for each
member and return a Y if the Prim_Class for the member = Lineman, or N if the Prim_Class for the
member is NOT Lineman.

Attribute: IsClassLinemanQ
Formula: contains(Prim_class,Lineman)

For any member that is a Lineman, IsClassLinemanQ will contain Y
For all other member-classifications, IsClassLinemanQ will contain N

Likewise, for the Status attribute: we create a new attribute that uses the contains formula to look at
the Status attribute for each member and return a Y if the Status for the member = Working, or N if the
Status for the member is not Working.

Attribute: IspersonWorkingQ
Formula: contains(Status,Working)

For any member that is Working, IspersonWorkingQ will contain Y
For all other member-statuses, IspersonWorkingQ will contain N

Now we have two attributes that are returning a Y or a N. How can we combine these 2 attributes into
one that we can use to evaluate the member against our criteria?

We can concatenate (concat) the two attributes’ results into ONE attribute (our “code”) …

Attribute: PriClassAndStatus_Concatenated
Formula: concat(IsClassLinemanQ,IspersonWorkingQ)

…and then use contains to see if the “code” contains a Y.

Attribute: IsPriClassORStatusY_Contains
Formula: contains(PriClassAndStatus_Concatenated,Y)

At the Crews level, the following attribute would show how many members of the crew meet the
criteria (Either or Both):

Attribute: HowManyPriClassORStatusYQ
Formula: summarize(IsPriClassORStatusY_Contains)

Modifying this formula slightly and carrying it up to the Groups level will allow us to look at a table that
will count the number of members with a Y for either or both criteria.

Without taking any additional steps for formatting, the table based on this attribute might look like this:

The information in the table indicates that 15 members are neither Linemen nor Working (their “code”
would be NN), while 40 members are either Linemen OR Working OR both.

Example 2

In this example, we will add on to our Use Case 1 so that we get more detailed and valuable information
out of Crew Manager/into our dashboards.

In Example 1, we considered whether members met either 1 or both of 2 criteria. Our dashboard
counted members that met either 1 or both (as a count of Y) and members that met neither (as a count
of N).

We will build on the foundation of Use Case 1 to create a more meaningful dashboard.

First, we will build out the attributes and formulas for a 3rd criteria – Utility-employee or Contractor employee?

In the same way that we created the attributes and used formulas to identify members as Linemen (Y)
or not Linemen (N); and in the same way that we created the attributes and used formulas to identify
members as Working (Y) or not Working (N); we will create attributes and use formulas to determine
whether a member is a Utility employee (Y) or a Contractor (N).

We will use the VRUID attribute for the criteria, recognizing that Utility employees will have VRU IDs and
Contractor employees will not. Note that we could have elected to use another attribute that would
have allowed us to differentiate between utility employees and contractor employees.

Further, noting that the VRUID is numeric, we can use the greaterThan formula to analyze this attribute.

Referring to the VRUID attribute, we can create
Attribute: Has_VRU
Formula: greaterThan(VRUID,0)

This gives us our 3rd Y/N member level attribute, Has_VRU. Notice that with this attribute (compared
to the previously used IsClassLinemanQ and IspersonWorkingQ) a Y will be used to exclude the member
from our consideration rather than to include him. That is, a Y indicates the member is a utility
employee and we are trying to count members that are NOT utility employees.

Remember how we concatenated the attributes’ datapoints into one attribute,
PriClassAndStatus_Concatenated, in Use Case 1? We are going to follow a similar process to arrive at
the following possible values, in the new attribute that contains the Y/N datapoints for the 3 criteriaattributes – Class, Status, VRUID:

IsClassLinemanQ	IspersonWorkingQ	Has_VRU	Concatenated Value	FUNSUM, for dashboard
Y	Y	Y	YYY	Lineman Working (Utility)
Y	Y	N	YYN	Lineman Working (Contract)
Y	N	N	YNN	Lineman NotWorking (Contract)
N	N	N	NNN	NotLineman NotWorking (Contract)
N	N	Y	NNY	NotLineman NotWorking (Utility)
N	Y	Y	NYY	NotLineman Working (Utility)
Y	N	Y	YNY	Lineman NotWorking (Utility)
N	Y	N	NYN	NotLineman Working (Contract)

If we add an additional datapoint, FUNSUM, to the attribute we created to hold the concatenated value
of the 3 criteria-attributes:

Attribute: ACM_ConcatYYY
Formula: concat(IsClassLinemanQ,IspersonWorkingQ,Has_VRU)

We can drive toward a more explicit dashboard, with values as indicated above and partially shown in
the example, below:

(Note: the values for FUNSUM in the screenshot above do not match the values in the table, further
above.)

Then we summarize the attribute with the FUNSUM datapoint:

At the Crews Level:
Attribute: ACM_FUNSUM
Formula: summarize(ACM_YYYdatapoint)

Attribute: ACM_YYYdatapoint
Formula: dataPoint(ACM_ConcatYYY.FUNSUM)

And carry the summary up to the Group Level:
Attribute: ACM_GroupFUNSUM
Formula: summarize(ACM_FUNSUM)

Our dashboard would look something like this:

Obviously, you could change the way you name your datapoints, so that the table in the dashboard is
easier to read than our example. Consider that you could leave the FUNSUM value blank for cases you
have no need to summarize i.e., do not enter a FUNSUM value for YYY, for NNY, for NYY, for YNY – all
the Utility-related cases – and then use the “Gray Trick” to hide these counts in your table.

The “Gray Trick” uses the code for the color gray (#fefefe)

Additionally, this logic could be adapted to examine different criteria as well.

Example 3

The most common use of Resources may be to manage Work Orders. However, Resources can be used
in many ways. We could use Resources to represent pieces of equipment; shuttles; certifications; and
many other things. In this example, we will represent Meal Providers – those entities that will provide
breakfast, lunch and/or dinner to the crew members at our staging areas - as a Resource.

Keep in mind: You’ll want to have your requirements well-thought out before beginning to build your
Resources, to avoid doing a lot of work that leads to a dead end. We originally considered using
Resources to represent meals for workers, but after some discussion, realized there would be limitations
in this approach that could be avoided by representing the provider as the Resource. Feel free to
contact ARCOS if you would like to discuss your intended use of Resources.

So, first we will create the Meal_Provider resource. Click on the ‘blue Resources’ button and use the
Add button to create a new Resource Type. If the Resource Type you need is already present in the
drop-down list, simply choose it. Then hit Save.

Next, we need to define the Attributes we will need to manage the process of providing lunches. After
discussion, we know we will need:
• The name of the provider
• The types of meals the provider can produce
• The provider’s capacity – that is, how many meals can the provider produce

Additionally, we will need to be able to track:
• How many meals we order
• How many meals are taken/eaten by workers

So let’s create the following attributes on the Resource, “Meal_Provider”:

capacity	we will be able to enter the capacity for each meal provider we define
mealtype	we’ll add breakfast, lunch and dinner values
numordered	this number will be entered when the order is placed
numtaken	this number will come from the number of crew members picking up their meal from this provider

We’ll use the + to add the mealtypes this provider can produce.

We’ll enter the capacity of the provider.

We won’t enter numordered yet, because we haven’t ordered any meals

Finally, hit the + beside the Meal_Provider Name to add the new provider.

Now, if we’ve set up our badging correctly, our provider, Panera Bread, will have badges for capacity,
mealtype and numordered visible in the Resource Panel.

We can use these attributes in either of 2 ways: we could determine which crews will get lunch from
Panera Bread and then, using the number of crew members to determine how many meals we need, we
can order that number of meals, presuming Panera Bread can accommodate us. And if we see that the
number of crews needing lunch will exceed Panera’s capacity, we can pull a crew from Panera and have
some other provider feed that crew.

OR we can order the number of meals the provider can produce, and then assign crews so that all the
meals ordered are used.

For this example, we are going to order as many lunches as Panera can provide, and then distribute
those meals to as many crews as we can – trying to waste as few meals as possible.

So that we can drag the Resource – Panera Bread – onto our crews, we need an assignment attribute at
the crew level. Let’s create:

Attribute: Meal_provider_assign
for this.

We need to [edit this attribute and] identify this attribute as a Resource Assignment. And we need to
identify the Resource Type (Meal_Provider) this attribute is assigned. Also check the boxes for Shared
and Multi-Assign. In the attribute panel, for this Crews level attribute, toggle the List entry (Badge
column) to B – so that the provider assignment will appear in Both the Resource Panel and the Crew
Panel. (see below)

Now, double-click on the numordered badge for Panera Bread in the Resource Panel, and enter the
number of meals you’re ordering. We’re going to order Panera’s capacity of 34.

Let's create the numtaken attribute now. This attribute will equate the number of members of a crew
with the number of meals that crew will take.

For each crew, the number of members of that crew will ‘take’ a meal – increasing the value of the
numtaken badge - from the number of meals we have ordered.

But what if we try to feed more workers than Panera can feed?

We can use additional attributes and formulas to ensure we are aware of this situation.

We can use a formula-based attribute to look at the difference between the number of meals ordered
and the number of meals taken. If the difference is 0 we know every crew member got lunch. If the
difference is less than 0, then someone will go hungry – so we will turn the badge - and the resource if
we want - RED.

There’s lots more we could do here, like adding a duration to the meals so that the need for lunch is a
finite, daily situation; fine-tuning attributes to allow us to recognize cases where not all members of a
crew need lunch; and building out more data points to meet your specific reporting needs.