Helping SMBs choose the right recruiting technology

Recently I was asked to participate in a podcast regarding recruiting technology and how small businesses can filter through the clutter of information and solutions out there. Feel free to listen to the whole podcast series as well as topics on effectively evaluating candidates, challenges of SMB recruiting, and building talent pipelines.

It is my belief that regardless of company size there is a commonality of issues recruiters face, it is just a matter of the intensity of those issues that varies based on size, industry, location, etc. There is one thing that needs to ring true across all business sizes, and even more so for smaller businesses – pragmatism.

I am a firm believer of looking at what you are trying to do and boiling it down to doing a few things really well before you start thinking beyond those core things. For example, a great starting point is to ask yourself one basic question: Do I have too few or too many applicants?

By answering this question you can begin your quest to finding the right technology.

You can answer this question, regardless of your size, by first looking at where you are sourcing. If you are limiting yourself to Craigslist, your social channels and maybe Indeed, you are not reaching enough candidates, and hence your low applicant flow. What is your SEO strategy for your jobs? What other ways can you post simply and effectively? If you have too many candidates, look at more niche, specialized job boards rather than the big guys. Focus on how you word your job descriptions to zero in on target candidates. And finally, spend a bit of time looking at where you have found quality candidates in the past and try to mirror those successes.

There is a lot more that we covered in the podcast, but hopefully this is a teaser to get you thinking about what matters to your business.

Get more information on choosing the right recruiting technology. http://bit.ly/2gWvXJ2 #SAP #SAPCloud #AI

What is Blockchain?

Blockchain has long been resonating beyond the walls of the software industry. Every day, messages circulate about the development of the Bitcoin price index, while startups are competing to create the next earth-shattering business model based on this technology.

Yet what do we really understand about it?

At the peak of the 2008 financial crisis, an individual or a group of individuals acting under the pseudonym Satoshi Nakamoto sent a paper entitled “Bitcoin: A Peer-to-Peer Electronic Cash System” to a mailing list. It contained a practical solution to a problem that had left virtual currency theorists scratching their heads: the Byzantine General’s Problem.

Creating Consensus Among Decentralized Players

The Byzantine General’s Problem originates in an historical legend at the time of Constantinople’s fall to the Ottoman Empire in 1453. The fortified city could only be successfully overrun with help of carefully planned troop movements coming from various directions. To achieve this, the commanding Ottoman generals had to resort to communicating through messengers. However, the decision about the moment of attack was severely hampered by one key detail: As some of the generals wanted discredit their colleagues to the sultan, they purposefully provided false information to instigate a premature attack. From that point on, none of the generals could be sure if the incoming messages were authentic or not.

The crux of the problem was the issue of consensus, deriving from the fact that the individual decision-makers could not trust one another.

Money and the Role of the Intermediary

The same situation applies to digital transactions of value. How can we reach consensus that a virtual dollar will not be paid out twice? To date, the answer could not have been simpler: by involving an intermediary third party to oversee all transactions; in other words, a bank.

This isn’t always smooth sailing. International payments in the form of SWIFT transferrs often take several days to process due to the various parties involved. This increases the transaction costs and makes small one-off payments inconvenient. The option of being able to cancel a transaction also has its pitfalls; to be able to minimize fraud, providers of irreversible services are required to collect more information about their customers than is usually necessary.

Yet for physical value transactions the problem has been largely resolved. Take the following example: If Alice wants to pay Bob a certain sum of money, it is sufficient for her to hand him a counterfeit-proof coin that represents the respective value. It is impossible for Alice to make two separate payments simultaneously using the same coin.

There have been many attempts to convert the principle of physical currency into the digital world, yet with varying degrees of success. Bitcoin was the first to largely meet these demands.

Cryptographic Signatures and Digital Value

To ensure that digital coins can only be spent by their lawful owners, Bitcoin uses public-key cryptography. This involves a private key made up of randomly-generated numbers, which, in turn also derives a public key. Conversely, public keys cannot be used to derive the corresponding private key. A digital signature is generated from the private key and a set of data. The public key enables users to determine that the signature derives from the corresponding private key, without needing to know it.

Bitcoin also uses the cryptographic hash function, which converts large strings of data into fixed-length data values, otherwise known as a hash. A good hash function is characterized by a high level of security and can assign various input quantities using as few of the same hashes as possible.

Compared to an encryption, this process cannot be reversed. When applied to the same input quantity, the hash function always produces the same hash yet it cannot be attributed to the original input quantity. Every change to the input quantity generates a completely different hash. For this reason, hashes are also known as digital fingerprints.

A coin in the Bitcoin system is ultimately a combination of digital signatures. The coin is passed on when the owner (Alice) digitally signs a hash from the previous transaction and the receiver’s (Bob) public key. For Bob to be sure that Alice has not already used her coin in another transaction, all transactions are publicly available.

Mathematical Race to Reach Consensus

Bitcoin achieves this through a peer-to-peer network. A network node compiles various transactions together in a block, generates a hash from them, and releases it with a time stamp. Each block contains the hash from the previous block, thereby forming a chain: the blockchain.

This brings us back to the “Byzantine General’s Problem”: all nodes must agree on which transaction has taken place first and whether another block should be added to the chain. Bitcoin here uses the so called proof of work method. To add an additional block to the chain, the respective computer nodes are required to solve a complex mathematical puzzle. The node that first finds the solution then shares it with all the other nodes. Once the solution has been verified by them, every node adds the block to their copy of the chain. The process then starts all over again.

To comply with the changing total computing power in the network, the difficulty of the puzzle is constantly adapted, so that new blocks are added to the chain approximately every 10 minutes. If two blocks are found simultaneously, the next block found determines which sub-chain will be kept. The longest chain wins.

Since the puzzle must be re-solved for every change to the block, which is also the case for all subsequent blocks, the chain becomes more secure the longer it becomes. To change it, an attacker would have to re-solve the mathematical puzzle for all blocks before being able to add a new block to the chain. The element of trust, which currently exists in the form of a bank, is thereby contained within blockchain’s mathematical logic.

The Internet of Value

Blockchain functions as a distributed public journal that records irreversible transactions. Users can quickly and cost-effectively verify and audit their transactions without intermediaries.

Use cases of public blockchain have the potential to completely transform existing markets

Blockchain technology use cases are by no means restricted to Bitcoin. Blockchain is far more a message about the transmission of value — the “Internet of Value.” The database serves as the ultimate determination of ownership rights. All kinds of assets that can be transformed into digital twins can be included in blockchain: diamonds, buildings, good deliveries – the possibilities are endless.

Whether this innovation is disruptive or incremental depends on the areas of operation. Reaching consensus within or between companies means evolutionary change, while use cases of public blockchains have the potential to completely transform existing markets.

One blockchain use case is Everledger, a startup that produces digital twins for diamonds. These digital twins are calculated from 40 data points and are stored on blockchain, enabling the stone’s ownership to be traced from when it first mined to when it becomes a piece of jewelry. Over 1 million jewels have already been digitally secured — a real success story.

Learn more about how SAP is bringing blockchain to the enterprise. http://bit.ly/2yzvJkS #SAP #SAPCloud #AI

IBP – Ariba SCC integration (part I – Setting up IBP)

Dear community members,

I am starting a mini blog series to describe the integration between IBP and  Ariba Supply Chain Collaboration (SCC). The content is based on my hands-on experience and it will be structured as follows:

* Part I   – Setting up IBP
* Part II  – Setting up Ariba SCC
* Part III – Running the integration E2E

Integration Overview

The integration with Ariba Supply Chain Collaboration (SCC) is facilitated by the Business Network Collaboration, a feature of the Control Tower module.

Key benefit: there is a direct connectivity between IBP and Ariba SCC, which means there is no need for a middleware. The Integration is based on cXML messages, a protocol created by Ariba and based on XML.

Now, following the steps from the Application Help, let’s review the settings that must be configured on IBP side.

Communication System

Open the Communication Systems fiori app and choose a new entry to define the communication system required for the integration with Ariba. Once that you have provided a name for the System ID and the System Name, the communication system is created and you will need to:

* maintain service.ariba.com under the hostname
* choose outbound authentication method as None

Communication Arrangement

Open the Communication Arrangement app and add a new Entry. You must choose the SAP_COM_0201 Communication Scenario which corresponds to Ariba. In the next screen, you will provide the communication system name you created in the previous step. Besides this, the rest of the fields will be prefilled.

However, you may want to review the Job Execution section where the default value is 02 Minutes. This value indicates the frequency of the polling job, how often IBP will check if there are any incoming cXML in the queue coming from Ariba’s end. To make an analogy here, this is similar to the CPI-DS agent which is scheduled to check every 40 seconds or so if there is any integration job triggered from IBP side.

Authentication Method 

There are 2 ways you can manage the authentication of the cXML you are sending on Ariba side. Details are available here.

Manage Data Sharing Plans 

This app is the place where the interface between IBP and Ariba SCC is defined. There are 4 main sections:

* General information: the settings maintained here are available for all the business partners that are part of this plan. For example, you define the planning area, the communication arrangement and the sharing mode which can be provider (outbound from IBP) or consumer (inbound to IBP).

* Plan Attributes: the attributes defined here are available in all data sharing arrangements within the plan.

* The first one that I maintained in the Ariba Network ID (ANID) which is the identification number of an Ariba network account. This attribute is not available in IBP but it is needed for Ariba to know how to process the incoming data.
* The second one is the Supplier ID. I left the default value empty, as the supplier ID, in my case, was defined differently for each communication arrangement.

* Mappings: in this section, we specify how the source elements should be mapped to the target elements.

In my example, I mapped the Supplier Forecast key figure using the attributes of its base planning level: WEEK, Product ID, Location ID (Supplier ID) and Ship-To Location ID. Sending the forecast on a different level of aggregation is possible too.

* Arrangements: these data arrangements specify which data is shared and with which business partner.

The general information area contains the settings that apply to the data sharing arrangement. A very important field is the Visibility Filter which controls which data is shared with the supplier mentioned under the Arrangement Attributes. You notice the two attributes available in the Arrangement Attributes sections are those defined one step higher in the hierarchy, at the Data Sharing Plan level.

Once you completed all these settings, don’t forget to enable the data sharing plan!

If you would like to preview the content of the communication arrangement, while you are in view mode, click on the Preview button next to your arrangement. This will open a csv file which contains the planning object combination for which the data will be extracted.

Running the Integration from IBP to Ariba 

Triggering the data integration from IBP to Ariba can be done both from fiori and excel UIs (application job).

In the current release (1708) the monitoring of the cXML is not available from the front-end but this is expected to be enhanced in the next release!

Stay tuned for the next post where I will describe the required settings on Ariba SCC side.

Best

Alecsandra

  http://bit.ly/2gWCt2r #SAP #SAPCloud #AI