Author: admin

Schoolhouse Electric, Portland-based maker and retailer of handmade, iconic lighting, furniture, and domestic home goods, was founded on family values and quality.

To reinforce that sense of family and community, owner and founder Brian Faherty joins his team of employees each day in the Portland, Oregon, warehouse, which happens to be where his wife also works. He’s the inspiration behind the products, which are vintage with a minimalistic utilitarian and even retro aesthetic.

Handmade is Best-Made

Chris Tufts, vice president of operations and finance at Schoolhouse Electric, recently joined me on the phone to discuss how Schoolhouse is adapting digitally while also maintaining its artisan craft. As we talked, I could hear the bustling of creation and laughter in the background. His desk borders the lighting assembly center at the flagship store in Portland.

In the past, it was difficult to compete with the Amazon and Google retailers of the world that can ship a product to customers in as little as two days. Most products sold by Schoolhouse are assembled by hand (even hand-sewn pillows and cushions), a process that takes time and precision.

In addition, 80 percent of product parts are purchased from U.S.-based mom and pop suppliers, some of which provide custom-made parts for Schoolhouse.

“Ordering from mom and pop vendors is a challenge when it comes to scaling up, but it’s a great asset to the product that we can offer and the quality that’s included,” Tufts said.

Today’s customers expect fast delivery and reasonable prices, so to scale growth and cut lead time, Schoolhouse decided on SAP Business ByDesign, a full cloud ERP suite, to manage its business and provide near real-time visibility into supply, inventory, and customer trends.

Before implementing and going live with SAP Business ByDesign, Schoolhouse Electric staff performed a manual, quarterly inventory assessment on 2 million pieces of inventory. The process required the warehouse to close for a full weekend each quarter.

“It was a mess unquestionably. The results of the inventories might have been more harm than good depending on who you had counting different things and whether they could tell one washer from another.  It was pretty messy,” said Tufts. “With SAP, we have a regular ongoing constant cycle counting. We know exactly what inventory accuracy is by floor, by product segment, and we can track that to a high degree of detail. We know where and how much of each part we have.”

In addition to keeping parts on hand, Schoolhouse discontinued ordering obsolete parts.

“Without SAP, it was hard to visualize all of the material needed to make a product that has a five- to 10-part assembly process. By tracking our builds and materials in SAP Business ByDesign, we now have quick answers, and we’re able to quantify the impact and strategize how many of each product we can make in a certain timeframe. Today we are at 98 percent product availability, an increase from 70 percent in early 2016,” said Tufts.

Growth with Industrial Roots

Schoolhouse Electric plans to open a third store in Pittsburgh, Pennsylvania, a former industry hub of the U.S.  The city is a perfect complement to the Schoolhouse style. It’s a new hub for technology leaders like Uber and Google, the cost of living is reasonable, and there are many universities in the area.

Tufts closed our conversation mentioning that without the cloud ERP solution, Schoolhouse Electric wouldn’t exist in the market. The third store in Pittsburgh would not be a reality: “Without SAP, we wouldn’t be the size that we are. We wouldn’t be growing 25 percent year-over-year because we simply wouldn’t have had the competitive lead times, and we wouldn’t have been able to fulfill customers’ products as we committed. Our business benefits are stronger than enabling growth.  It would really not be happening had we not gotten into a cloud ERP system.”
—

Learn how SAP Business ByDesign can help your
small to midsize business here.

—

To implement SAP Business ByDesign successfully, Schoolhouse Electric partnered with Navigator Business Solutions. Learn more here.

Follow me on Twitter: @CMDonato.
This story originally appeared on the SAP Community. http://bit.ly/2BzQ8HQ #SAP #SAPCloud #AI

Nowadays, most part of the organizations make use of Key Performance Indicators (a.k.a KPIs) to evaluate their success in different activities relevant with their business. A KPI is a measurable value that demonstrates how effectively a company is achieving its objectives.

When we relate KPIs with the SAP Fiori experience the first thing that comes to our minds is the use of SAP Smart Business Applications and the KPI Modeller (more information available here), but what most part of the developers don’t know is that this is not the only path available to publish KPIs in an SAP Fiori application.

We know already that Fiori Elements can generate UIs at runtime based on metadata annotations and predefined templates, but one of the most interesting functionalities (and not so widespread) is the ability to publish KPIs using the @UI.dataPoint annotation.

With a measurable field (number, price, quantity or percentage) you can define a threshold and evaluate how the indicator has been performing and display the result in a range of different colors and symbols. This concept is defined as Trend-Criticality Calculation and you can check the official documentation here.

The focus of this post is to explain only the Criticality calculation inside an Overview Page application, but since there are different Fiori Elements providing support to the annotation @UI.dataPoint is possible to adapt the same concepts for different kind of developments (e.g. KPI in the header of an Object Page).

This post covers not only Fiori and UI5 concepts but also ABAP CDS, if you are not familiar with these concepts I advise you to check my previous posts or to have a look in SAP official documentation.

What do I need to know about Criticality?

In a criticality calculation we need to provide the following data:

* Improvement direction
* Threshold (low and high values)

Depending on the selected direction we must define multiple low and high values, let’s check in details the available directions and the expected threshold values:

* #TARGET: Your key figure must stay inside a specific target in the center of your threshold, deviations in any directions will reflect a bad performance of the indicator.

* Example of an use case: Headcount.

* #MINIMIZE: Your key figure must stay in the lowest part of the threshold to indicate a good performance, deviation in the opposite direction will reflect as bad performance.

* Example of an use case: Work Incidents.

* #MAXIMIZE: Your key figure must stay in the highest part of the threshold to indicate a good performance, deviation in the opposite direction will reflect as bad performance.

* Example of an use case: Sales.

 

Now that you are able to identify the available scenarios we can start the development of our demo. To construct our application we will use data from SFLIGHTS standard view and create a KPI to check the seating occupancy for each one of the scheduled flights in the system. Comparing the number of occupied seats against the maximum seats available in the plane is possible to generate a percentage value and evaluate the position with a criticality calculation.

The improvement direction in this case must be #MAXIMIZE because the airline wants to sell all the seats available in the plane, if the indicator is showing entries with red color it basically means they need to focus sales in those particular flights with a low occupancy.

The UI5 application will be based on an Overview Page template with a List card with progress bar. When we combine a data point annotation with this card template the framework populates automatically the colors and completion of the bar.

As usual, I’m splitting this post in 3 sections:

* ABAP CDS
* OData Project
* UI5 Project (Web IDE)

ABAP CDS

Create the view ZDEMO_CRITICALITY_OVP and select data from the view SFLIGHTS. The following fields are expected as the result:

* FlightCode: The union of the airline code (CARRID) and the connection number (CONNID). This field should be available inside the list card and in the global filter of the Overview Page.
* FlightDate: Date of the flight, configured as a secondary data point in the list card.
* Destination: The arrival city, expected in the result of the card as well.

* Occupancy: A percentage result based on the calculation of the maximum seats (SEATSMAX) against the occupied seats (SEATSOCC). This field should be configured as a data point to become a KPI about seating occupancy. Extra configurations determine only 2 fractional digits, expected values between 0 and 100, and a criticality calculation with a maximize direction with the following range of colors:

* RED from 0 to 25.
* YELLOW from 26 to 60.
* GREEN from 61 to 100.

* Percentage: Just a unit of measure to associate directly with the occupancy field.

@AbapCatalog.sqlViewName: ‘ZDEMOCRITOVP’ @AbapCatalog.compiler.compareFilter: true @AccessControl.authorizationCheck: #CHECK @EndUserText.label: ‘Criticality OVP’ @OData.publish: true define view ZDEMO_CRITICALITY_OVP as select from sflights as Flight { @EndUserText.label: ‘Flight Code’ @UI: { selectionField.position: 10, lineItem.position: 10 } key concat(carrid, connid) as FlightCode, @UI: { lineItem: { type: #AS_DATAPOINT, importance: #HIGH, position: 20 }, dataPoint: { title: ‘Flight Date’ } } key fldate as FlightDate, @UI.lineItem.position: 20 cityto as Destination, @UI: { lineItem: { type: #AS_DATAPOINT, importance: #HIGH, position: 10 }, dataPoint: { title: ‘Flight Date’, valueFormat.numberOfFractionalDigits: 2, minimumValue: 0, maximumValue: 100, criticalityCalculation: { improvementDirection: #MAXIMIZE, deviationRangeLowValue: 25, toleranceRangeLowValue: 60 } } } @Semantics.quantity.unitOfMeasure: ‘Percentage’ division(seatsocc * 100, seatsmax, 2) as Occupancy, @Semantics.unitOfMeasure: true cast(’ % ’ as abap.unit(3)) as Percentage }

Important points about the annotations used in this CDS view:

* @OData.publish: Used to publish the OData service automatically without the need to create an OData project through transaction SEGW.
* @EndUserText.label: This annotation provides a label to the field.
* @UI.selectionField: This annotation determines the position of the field in the global filter of the Overview Page.
* @UI.lineItem: This annotation determines the position of the fied inside the cell of our list card.
* @UI.dataPoint: This annotation holds the criticality calculation of our KPI. Notice that we use #MAXIMIZE as the improvement direction, so we just need to fill deviationRangeLowValue and toleranceRangeLowValue to determine the threshold (as described by SAP documentation). Also, there is a configuration for decimal places and the minimum and maximum values expected for the field.
* @Semantics.quantity and @Semantics.unitOfMeasure: These annotations define a relation between a quantity field and its respective unit.

This is the expected outcome:

OData Project

There are 2 ways to create your OData project consuming ABAP CDS views:

* Create a new project through SEGW transaction and include your CDS views by Reference. Just right click on the Data Model folder and select Reference -> Data Source.

* Include the @OData.publish annotation in the header of your CDS view, the system will create your OData project automatically based on the field structure and annotations.

@OData.publish: true define view ZDEMO_CRITICALITY_OVP as select from sflights as Flight { … }

Remember always to activate the OData service in the Front-end server (SAP Gateway server) through the transaction /IWFND/MAINT_SERVICE.

UI5 Project (Web IDE)

The process to create an UI5 application through Web IDE is pretty simple and straightforward, just follow the steps below to create an Overview Page with a list card with progress bar.

Right click in your Workspace folder and click New -> Project from Template.

Template Selection: Create a new project based on a Overview Page.

Basic Information: Define the project name as zdemo_criticality_ovp.

Data Connection: Select your system and OData project.

Annotation Selection: Select the remote annotation provided by the ABAP CDS exposure.

Note #1: All the annotations published in our ABAP CDS view will flow to the UI5 application through this remote source ZDEMO_CRITICALITY_OVP_CDS_VAN. Later on you can see the same annotations inside the XML file inside the localService folder.

Template Customization: Define a namespace, data source, entity type, app title and description. The rest of the configuration doesn’t affect this demo.

Finish the wizard and conclude the creation of your Overview Page.

Now we need to configure a List card inside of our application, right click in the main folder of your project, click New -> Card.

Configure Datasource: Select the existing data source and continue.

Select a Card: Select a List card template, no need to mark the extra configuration in the bottom.

Template Customization: Select the entity set, provide a title and fill the card properties with the following data:

* List Type: Extended
* List Flavor: Bar
* Sort By: Flight Date
* Sort Order: Descending

Finish the wizard and conclude the creation of your new card.

Note #2: The list flavor must be set as Bar to allow the use of progress bar and provide support to data points with criticality calculation.

Note #3: The list type must be set as Extended to provide extra space for all of our fields.

Note #4: The sort order was just configured like this to increase our chances to find flights with low occupancy during the tests.

Now the application is concluded and we can start the tests, just filter by Flight Code to navigate across different KPI results. Since we configured a sort by Flight Date the chances to find flights with low occupancy are higher. Check some examples below:

SQ0015 (Singapore)

AZ0555 (Frankfurt)

LH0402 (New York)

LH2402 (Berlin) http://bit.ly/2BB9Y5e #SAP #SAPCloud #AI