3 Ways The Social Age Will Inspire Your Business
TAKE NOTE (Insights into SAP solutions and Emerging Technology)
The Industrial Age is dead. Social media has arrived. Everything has changed. And I had no idea what I was doing.
In early 2014, I was a social media neophyte peering down over the edge into the vast social sea. If I wanted to succeed and survive the social leap, I needed knowledge, a digital identity, and a solid online network.
Social media was a serendipitous treasure chest of valuable content and helpful people. Each day I dedicated time to research, reading, learning, and engaging. High-quality resources and a growing network accelerated my status from social newbie to social saveur in less than a year.
But saveur status doesn’t last long in the world of social. Disruption rules in 2015. Social is constantly morphing and evolving, creating “new normals” we must learn and integrate to stay ahead.
You must always be on the line of learning in the Social Age.
My learning led me to Ted Coiné and Mark S. Babbitt’s book A World Gone Social. Spot-on insights, provocative questions, and revealing stories inspired new ways to think about social.
Here are my top 3 takeaways from the social survival guide:
1. “More Social, Less Media”
This is your new daily mantra.
Social is hard work: there are no shortcuts to social success. The days of broadcasting are over. People don’t connect to brands, they connect to other people.
Success will come to those who embrace and integrate these four simple words into their business. Organizations must cultivate a culture of engagement, innovation, and collaboration. Creating and nurturing relationships with employees and customers are top priorities for social success.
2. “Go Nano, Or Go Home”
Larger organizations have two things smaller businesses typically don’t: deep pockets and serious status. But social media is the arrow aimed straight to the heart of these large enterprises. “The Death Of Large” is knocking on the doors of legacy enterprises that don’t embrace social.
The once prevalent megacorporation is being replaced by a smaller, more social and collaborative model. The agile “nano-corp” can move from one organization to another, getting more done in less time.
Agility is key to surviving the disruptive forces of social.
3. “Flat Is The New Black”
How about this for disruption:
- What if every employee made big decisions?
- What if you refuse to be treated as “the boss?”
- What if there we no more office meetings?
- What if the best parking spaces go to the earliest risers?
Social is changing the world of work. Leadership is based on serving the team. Employees are active, engaged, self-managing contributors to the organization. Excess layers of management are stripped away. It’s a world gone social and a world gone flat.
- Will large enterprises let their hierarchies fall flat?
- Will flat management be the new black socially forward businesses try on in 2015?
- Will flat organizations be the only ones to survive in the Social Age?
Social is here to stay. We must be anticipatory, agile, and armed with the right tools and mindset to survive and thrive in the Social Age.
This story originally appeared on The Talent Culture.
UNDER DEVELOPMENT(Information for ABAP Developers)
Which SQL Database Accesses Cause the Highest Load?
Picking up from last month, we will look at how to use the ST05 Performance Trace Tool to solve performance issues. Remember you’ve ruled out deficiencies in the system setup, mishandling by users, or the need for parallel processing, then you need to revisit your code and see if the source of your performance problem is hiding there in your SQL commands.
Central to any database access performance analysis is an understanding of which accesses cause the highest load. It’s only logical that this is where you concentrate your efforts. In order to identify which tables are excessively accessed, Performance Trace enables you to aggregate all accesses by the names of the tables. By summing up all the request times, you can see which accesses to which database tables are causing the highest database loads.
For instance, I will use SE16 and read table MSEG with no key fields entered and use the ST05 trace to record the SQL. As you would expect this takes a minute. Her is the output of the display trace below. By following the menu path Trace List=>Summarize Trace by SQL Statement or hitting SHIFT+F8 you can see the summary.
After activating the Summarize Function, you will see a list with the information aggregated for each table. The screen shot below displays a list that is already sorted by time to identify the database tables with the highest loads.
Obviously in our example the MSEG read was the highest. But in your trace, the high load might be caused by the number of accesses, the amount of read data, or by expensive SQL statements. Pick the highest loads, and focus on these first.
OK, then what? READ MORE
Q&A (Post your questions to Facebook or Twitter and get the answers you need)
Q. When it comes to JOINS vs. FOR ALL ENTRIES – Which Performs Better and why?
A. If I had a nickel for each time this was asked! If you use EXPLAIN SQL from within the ST05 trace, it will give you more information about the SQL and the way it is processed. PLEASE…Try it and see.
Generally, use INNER JOIN. Only use FAE (For All Entries) if one or more of the tables is a cluster or pool table, or you’ve tried all other optimizations and still have performance problems. (Also in BW start/end routines).
Major advantages of JOIN constructs are the flexibility of the access path (sequence of table accesses) based on runtime selection criteria (which can make a join exponentially faster than FAE with its fixed access path) and that your result ends up in one internal table, which is very often the requirement. You need much less code when using Joins.
FAE can come in handy e.g. when cluster/pool tables are involved, or very long lists of single selection values would make the SQL statement grow too large if used as a range for the IN-operator, or if the results are indeed required in separate internal tables.
The buffering issue is more complex. In case of many repeated accesses to few or single lines I would also avoid joins on buffered tables, however if I just read a reasonable amount of data once for list output, I have seen no significant disadvantage when buffered tables are involved (G/L account master data tables, for example).
So after many years of comparing and experimenting, I came to the conclusion to use Joins whenever possible, and use FAE in certain circumstances. You can have both in one statement as well.
It is a myth that FAE is usually better than INNER JOIN. The fact is, that FAE usually performs worse than INNER JOIN – but you may have a hard time arguing it. The myth is so entrenched.