While the Internet has made global commerce a reality, the online social services it spawned have also provided a worldwide megaphone for dissatisfied customers. From Bank of America’s reversal on debit card fees to Apple’s “antenna-gate” to Netflix’s pricing plan backlash, companies have struggled to respond effectively in the social space.

Where do they go wrong? In almost every case, they forgot one of these five rules of online customer service.

1. Respond

Failing to respond to even one unhappy customer can be costly. United Airlines found that out the hard way, when they broke musician Dave Carroll’s expensive Taylor guitar–and then ignored him. With 12 million views, the songwriter’s YouTube video tore the wings off more than $7 million in positive advertising.

Ignoring a complaining customer was a 20th century solution. Without the Internet, one angry person–even a hundred–might not have had much effect on the bottom line. Of course, that’s not the case in this age of social media, where one guy with a busted guitar can speak to millions.

2. Acknowledge

Bank of America sounded out-of-touch last fall when the company failed to acknowledge that it was making debit card fee changes that would negatively affect millions of its customers. Even after a rising tide of criticism, the bank still didn’t admit a mistake. Rather, it attempted to retry its losing case in the online court of public opinion … and lost.

Whether your customers are on Facebook, Twitter, or your company website, you need to remember that the world is watching. If you’re right, make your case simply, compassionately, and professionally. When wrong, admit the error clearly and candidly. Surveys show that customers admire company executives able to accept fault and willing to take steps to eliminate future situations.

3. Elevate

In June 2010, Apple CEO Steve Jobs made one of his few PR stumbles in response to a tsunami of complaints about the iPhone 4′s antenna configuration. Apple eventually admitted a problem, but not before Jobs infamously suggested to a blogger that users should just hold the phone differently. His comments only fueled the online firestorm.

Like Jobs, you’re proud of your company. Pride is fine, but don’t fire back–it’s only business, and needs to stay that way. No matter how personal the barrage, stay above the fray. If you’re right, respond only on the merits of the case. If you attempt to discredit a complaining customer–directly or by innuendo–you risk sounding like a bully. Gloating, blaming, and deflecting are all losing strategies.

4. Apologize

Last summer, stockholders were calling for Netflix CEO Reed Hastings’ head when he bungled the response to customer backlash over the company’s  restructured pricing. Hastings did apologize for the misstep, but still tried to argue his case in the Twitterverse even as his company’s stock price took a 40% nosedive.

If you’re wrong, admit the fault and apologize.  No excuses; no “buts.” An apology is not an opportunity to further the argument.

The rules of business apologies are no different than with your spouse. The only thing that should come after the apology is a promise to fix the problem and a pledge to never do it again–anything else and you’re liable to create more problems than you’ll solve.

5. Downsize

Handling customer complaints in the social media sphere is much different than a courtroom debate or advertising campaign. You lose almost all of the advantage of being a company. The discussion plays out on the small screen of your future customer’s computer. Waving the corporate flag isn’t going to be effective. You’ll need to downsize the discussion. Be casual, informative, and interactive. Don’t think of speaking to a group, but rather to every member of the Internet audience as a single individual.

If ignored, online complaints can undermine much of your hard work or even threaten your company’s future viability. On the other hand, pay attention to these five principles and you customers–current and future–will learn that yours is a  company that listens, admits fault, and corrects mistakes.

Decades of studies and surveys show that is an effective strategy to win and keep customers.

Source: http://www.inc.com/ron-burley/customer-service-5-rules-for-handling-complaints.html

When it’s time to grow a business, Keylock, senior vice president of new business development and partnerships at dunnhumbyUSA, suggests a word-of-mouth campaign through those loyal customers. “I generally grow my circle of friends through my existing ones, and in most cases this should be the same in business, but many companies and brands spend their time and effort chasing new customers,” he said.

Customer loyalty falling

According to The Effects of the Recession on Brand Loyalty and ‘Buy Down’ Behavior: 2011 Update by comScore, 54% of consumers said they bought the brand they wanted most in 2008. By 2010, that number dropped to 45% and further to 43% by 2011.

The comScore study, which illustrates the impact of the economic climate, found consumers are buying what’s on sale rather than staying loyal to a particular brand. This has opened the doors for businesses to enhance their customer base through a series of rewards and incentives programs where they are most likely to see them — on the Internet. The key is knowing which programs are most likely to attract loyal customers.

These marketing strategies range from search engine optimization (SEO) to pay-per-click advertising and newsletters. They include social media and social customer service management, mobile and even website registration. Furthermore, online metrics now present companies with immediate results, showing how well these customer loyalty programs are working, and that’s based on feedback and then number of visits to their sites.

“Since consumers are increasingly active in the social and mobile channels, most companies I talk to have developed or are increasing their online presence,” said Emily Murphy, a customer intelligence researcher with Forrester Research. “Marketers understand that consumers have increasing expectations for how and when companies will interact with them, and turn to the digital channels to fulfill that.”

Customer Service Still Comes First

Whatever program a company chooses, most industry watchers say the best way to generate loyal customers is through good customer service first and good loyalty programs second.

“The loyalty programs that work best are those in which a business really seeks to be loyal to its customers, drives this philosophy at a strategic level and implements it everywhere across the business–not just via a marketing tool,” Keylock said.

You don’t want to lose sight of your best customers — you may need to acquire more than 15 new customers to replace one loyal customer, he added.

But according to Murphy, the reality is more companies are using their loyalty programs as a strategy for acquiring new customers or members, not just a retention strategy for existing customers. Murphy breaks loyalty strategies into two categories that often work together: Explicit loyalty and implicit loyalty.

“Explicit loyalty is what we consider loyalty programs — enrollment programs with a structured give and get that often have their own P&L [profit and loss statement] within the organization,” Murphy said. “Implicit loyalty strategies are made up of any data-driven initiative aimed at increasing retention and improving customer satisfaction, for example, customer experience management. These strategies often work together.” Online account management and enrollment is vital for loyalty programs to work to the best of their ability, since enrolling at the point of service takes time and can turn away customers, she said.

Denis Pombriant, a CRM analyst firm Beagle Research Group, said companies shouldn’t be asking what loyalty programs work best but instead how to shape the attitude of the customers you’re targeting. This is something that is rarely explored beyond the realm of repeated sales.

“The value of loyalty is derived from things that are at best tangential to the purchase. For example, knowing customer support makes sense for your product is far more instrumental to loyalty and to promoting it than simply by looking at sales figures,” Pombriant said.

Assessing customer loyalty

Companies can assess customer attitudes toward a business by using software programs such as Get Satisfaction and Radian6. Get Satisfaction is primarily a service and support modality that helps keep customers in the fold so that they eventually buy again, whereas Radian6 lets vendors gauge customer sentiment.

“By tracking customer sentiment, companies can get far more revealing information than simple survey scores such as net promoter scores because sentiment precedes a loyalty decision,” Pombriant said.

Whatever approach to retaining new or old customers a company takes, in today’s net-centric world there is no reason every loyalty program shouldn’t be using analytics. Those metrics identify customers who have asked to be identified just by signing up.

“Program members are often more willing to give up identifying and personal information. So when loyalty programs target too broadly and don’t take advantage of that opportunity to engage these members, they’re doing themselves a disservice,” Murphy said.

“The customer intelligence function and loyalty programs make great bedfellows because applying analytics makes loyalty program segmentation, targeting and offer management smarter, while loyalty programs generate a lot of attributable data that feeds back into the customer intelligence function,” she said.

Path to successful loyalty programs

Successful loyalty programs are often multi-tiered to provide rewards with a high perceived value and target incremental behaviors. For most companies, these rewards come in the form of discounts.

“Many loyalty programs use external-facing tiers to make it easy for members to understand benefits and provide them with aspirational motivation,” Murphy said. “A customer that can see the distance to achieving the next level of benefits will be more likely to want to close the gap.”

Murphy also noted that companies are now integrating rewards and incentives with online social marketing programs. “They will incentivize tweets, product reviews and Facebook ‘likes’ to start a conversation with their members and engage with them in a new way,” she said.

Loyalty programs can also retain members with something called gamification, which doles out rewards that focus on experiences, such as tickets to a concert and improved service, such as a direct line to the call center.

With so many competing programs in the marketplace, this can lead to forcing that customer to choose between transactional loyalty, based on a single transaction, and long-term brand loyalty, which is based on an emotional response.

“It’s all about interacting with consumers when it’s convenient for them,” Murphy said. And not just through pay-per-click ads.

“How does bombarding customers with ads engender loyalty?” Pombriant asked. “If anything it frustrates people who want an uncluttered experience.”

Pombriant warns that companies should tread carefully when it comes to customer loyalty gimmicks. He agreed that the best way to generate the truest customer loyalty is through good customer service. Any vendor can offer a product at a price and sweeten the deal with a discount if a customer convinces a friend to join. Sure, that deal size may be multiplied through word of mouth. But it’s a model that could backfire without good customer service.

“The company may not have earned that display of pseudo-loyalty, and if the product or service is not up to snuff, the customer could suffer significant blow back,” Pombriant said. “Ultimately, the vendor could have many people angry rather than just one.”

At the end of the day, companies should connect across all online and office channels to ensure the customer’s experience with the loyalty program is consistent and keeps up with the many new online channels available.

“Creating different mechanics and solutions is more likely to fragment the customer experience and can erode loyalty,” Keylock added. He noted that companies can often use customer loyalty offers to reach out to new customers, but only when done correctly.

“Sophisticated customer insights and the ability to act on them with customer-specific offers and benefits that use the right channels and surprise and delight new customers do work very well.”

Source : http://searchcrm.techtarget.com/news/2240147692/Loyalty-programs-good-observers-say-but-customer-service-must-lead

2 – Yürürken kolları sallamak beynin performansını olumlu etkiliyor. Önemli kararlarınızı açık havada, kollarınızı sağa sola sallayarak yürürken almaya ne dersiniz?

3- Yabancı bir dil öğrenme beyni güçlendiriyor. Her gün birkaç yabancı ya da yerli yeni kelime öğrenip, kullanabilirsiniz. Sözlük okuyabilirsiniz. Alışveriş listesi veya telefon numaralarını ezberlemeyi deneyebilirsiniz.

4- Zihinsel jimnastik /antrenman yapın. Bunun için çeşitli bulmacaları çözebilirsiniz. Satranç gibi akıl oyunları oynayın.

5 – Rutin olarak tekrar ettiğiniz davranışlardan vazgeçin. Bazen telefonu sol elinizde tutun, çantanızı diğer elinizle taşıyın, evinize başka bir yoldan gidin. En azından bir günlüğüne televizyon kumandasını sık kullanmadığınız elinizde tutun.

6 – Entelektüel zevklerinizi geliştirmek için her gün mutlaka iyi bir özdeyiş antolojisinden birkaç cümle okuyun. Beyninizi kaliteli cümlelerle besleyin.

7 – Her gün güzel bir resme veya fotoğrafa bakmaya çalışın. Estetik algınız, gördüğünüz estetik şeyler kadar gelişir.

8 – Sevdiğiniz bir müziği bir süre gözleriniz kapalı dinleyin. Beyin otoriteleri tarafından klâsik müziğin zekâya 7 puan ekleyebildiği iddia edilmektedir.

9 – Günde aklınızdan 60 bin ile 80 bin arası düşünce geçer. Bu düşünceler ne hakkındaysa, hayatınız da ona göre şekillenir. Unutmayın, kafanızda en çok neyi düşünürseniz, hayatınızda da onu çoğaltırsınız.

10 – Bir konu hakkında düşünürken, nasıl düşündüğünüzü de gözlemleyin. Düşünmek üzerine düşünmek, beyin ve düşünce kapasitesini artırır.

11 – İyi bir uyku kaliteli bir beyin için şarttır. Çok uyuyorum diye üzülmeyin. Einstein‘in günlük 10 saatten fazla uyuduğu biliniyor. 24 saati geçen uykusuzluk beyinde sarhoşluğa benzer bir etki yapar.

12 – Bol ve temiz oksijen beyin için çok önemlidir. Beynimiz ağırlık olarak vücudumuzun yüzde 2’sini oluşturduğu halde, vücuda gelen oksijenin yüzde 25’ini tüketir. Oksijensiz kaldığımızda ölümü gerçekleşen ilk organımız beyindir. Odanızın penceresini açarak kendinize bol bol oksijen ısmarlayın.

13 – Farklı düşünme tarzları beyninizi geliştirir. Çocuklar ve hayvanlarla daha fazla vakit geçirin. Sizden farklı düşünen insanlarla konuşun.

14 – Kullanılmayan organ körelir. Sürekli televizyon seyrederek beyninizi “düşük viteste çalıştırmayın.

15 – Beynin en tehlikeli yanı “ters çaba” kuralına göre çalıştığı anlardır. Başınıza gelmesinden en çok korktuğunuz şeye odaklanırsanız, korktuğunuzu başınıza getirir; Buna ters çaba kuralı denir. Beyin odaklanılan hedef olumsuz olsa bile, bunu gerçekleştirmek için çalışır. Topluluk önünde konuşma yaparken “acaba heyecanlanır mıyım?” diye düşünürseniz, heyecanlanırsınız.

16 – Beyni yoran monotonluktur. Hayatınızı ne kadar renklendirirseniz, beyninizi o kadar neşelendirirsiniz.

17 – Beyin kısa süreli hafızada beş ile yedi arasındaki bilgiyi işleyebilir. Yeni bir bilgi gelince, bu bilgilerden birini atar. Buna “sihirli sayı” kuralı denir. Bu kural aşılıp aşırı bilgi yüklenmesi durumunda beynimiz “servis dışı” olur. Hayatınızın en büyük kararlarını alırken “kafadan “ değil, tıpkı beş haneli iki rakam grubunu çarparken yaptığınız gibi, bir kâğıt üzerine yazarak ne yapacağınızı hesaplayın.

18 – Sağlam kafa sağlam vücutta bulunur. Fiziksel zindelik, zihinsel zindelik getirir. Uzun süre hareketsiz kalmak, zihni de hareketsizleştirir. Spor yapmaya, fazla kilolarınızdan kurtulmaya özen gösterin. Yeterince su için. Çünkü, insan beyninin yüzde 78’i su ile kaplıdır.

19 – Ders çalışırken ilk öğrenilenler, son öğrenilenler, sık tekrarlananlar ve ilginç bulunanlar en çok akılda kalanlardır. Dersleri kısa aralar vererek çalışmak akıllıca bir harekettir.

20 – Bu hafta kafanızı nasıl daha iyi çalıştırabileceğiniz üzerine daha fazla düşünün. Unutmayın, beynimizi daha iyi çalıştırmak için kullanacağımız organ yine beynimiz“Aklınızı “başınıza” toplayın ve kullanın.

He doesn’t speak much about his past, but it is clear that he spent a lot of time in a soulless big company.

He is naturally friendly and outgoing, and quietly confident without being arrogant. So he finds it easy to pick up small gigs from the job board at the local Programmer’s Cafe. But he rapidly loses interest in insurance database projects, vanity web pages for housewives, and financial calculation engines.

After a year, he calculates that he has saved up enough money to pay his modest expenses for a year. So, after consulting with his faithful Alsatian, he sets up a computer in a sunfilled room in his rented apartment above the grocery store and installs a carefully-chosen selection of tools.

One by one, he calls his friends and warns them that if he seems remote over the next months, it is only because he is hard at work.

And he sits down to spin code.

And what code it is. Flawless, artistic, elegant, bug free. The user interface so perfectly mimics a users’ thought process that the people he shows it to at the Programmer’s Cafe hardly notice that there is a user interface. It’s a brilliant piece of work.

Encouraged by the feedback of his peers, he sets up in business and prepares to take orders.

His modesty precludes any pretensions, but after a month, the situation in his bank account is not looking encouraging. So far only three orders have been taken: one from his mother, one from an anonymous benefactor at the Programmer’s Cafe, and the one he submitted himself to test the commerce system.

In the second month, no more orders come in.

This surprises him and leaves him feeling melancholy. At the big company, new products were created on a regular basis, and even if they were inelegant and homely, they still sold in reasonable quantities. One product he worked on there went on to be a big hit.

After a few more months pass, his financial situation starts to look a little bit precarious. His dog looks at him sadly, not quite certain what is wrong, but aware that his face is looking a little bit gaunter than usual, and he seems to be unable to get up the energy to go out with friends, or go shopping to restock the dangerously low larder, or even to bathe.

One Tuesday morning, the local grocer has refused to extend him any more credit, and his banker has long since refused to return his calls.

The big company is not vindictive. They recognize talent, and are happy to hire him back, at a higher salary. Soon he is looking better, he has some new clothes, and he’s got his old confidence back. But something, somewhere, is missing. A spark in his eye. The hope that he might become the master of his own destiny is gone.

Why did he fail? He’s pretty sure he knows. “Marketing,” he says. Like many young technicians, he is apt to say things like, “Microsoft has worse products but better marketing.”

When uttered by a software developer, the term “marketing” simply stands in for all that business stuff: everything they don’t actually understand about creating software and selling it.

This, actually, is not really what “marketing” means. Actually Microsoft has pretty terrible marketing. Can you imagine those dinosaur ads actually making someone want to buy Microsoft Office?

Software is a conversation, between the software developer and the user. But for that conversation to happen requires a lot of work beyond the software development. It takes marketing, yes, but also sales, and public relations, and an office, and a network, and infrastructure, and air conditioning in the office, and customer service, and accounting, and a bunch of other support tasks.

But what do software developers do? They design and write code, they layout screens, they debug, they integrate, and they check things into the source code control repository.

The level a programmer works at (say, Emacs) is too abstract to support a business. Developers working at the developer abstraction layer need an implementation layer — an organization that takes their code and turns it into products. Dolly Parton, working at the “singing a nice song” layer, needs a huge implementation layer too, to make the records and book the concert halls and take the tickets and set up the audio gear and promote the records and collect the royalties.

Any successful software company is going to consist of a thin layer of developers, creating software, spread across the top of a big abstract administrative organization.

The abstraction exists solely to create the illusion that the daily activities of a programmer (design and writing code, checking in code, debugging, etc.) are all that it takes to create software products and bring them to market. Which gets me to the most important point of this essay:

Your first priority as the manager of a software team is building the development abstraction layer.

Most new software managers miss this point. They keep thinking of the traditional, Command-and-Conquer model of management that they learned from Hollywood movies.

According to Command-and-Conquer, managers-slash-leaders figure out where the business is going to go, and then issue the appropriate orders to their lieutenants to move the business in that direction. Their lieutenants in turn divide up the tasks into smaller chunks and command their reports to implement them. This continues down the org-chart until eventually someone at the bottom actually does some work. In this model, a programmer is a cog in the machine: a typist who carries out one part of management’s orders.

Some businesses actually run this way. You can always tell when you are dealing with such a business, because the person you are talking to is doing something infuriating and senseless, and they know it, and they might even care, but there’s nothing they can do about it. It’s the airline that loses a million mile customer forever because they refuse to change his non-refundable ticket so he can fly home for a family emergency. It’s the ISP whose service is down more often than it’s up, and when you cancel your account, they keep billing you, and billing you, and billing you, but when you call to complain, you have to call a toll number and wait on hold for an hour, and then they still refuse to refund you, until you start a blog about how badly they suck. It’s the Detroit automaker that long since forgot how to design cars that people might want to buy and instead lurches from marketing strategy to marketing strategy, as if the only reason we don’t buy their crappy cars is because the rebate wasn’t big enough.

Enough.

Forget it. The command-hierarchy system of management has been tried, and it seemed to work for a while in the 1920s, competing against peddlers pushing carts, but it’s not good enough for the 21st century. For software companies, you need to use a different model.

With a software company, the first priority of management needs to be creating that abstraction for the programmers.

If a programmer somewhere is worrying about a broken chair, or waiting on hold with Dell to order a new computer, the abstraction has sprung a leak.

Think of your development abstraction layer as a big, beautiful yacht with insanely powerful motors. It’s impeccably maintained. Gourmet meals are served like clockwork. The staterooms have twice-daily maid service. The navigation maps are always up to date. The GPS and the radar always work and if they break there’s a spare below deck. Standing on the bridge, you have programmers who really only think about speed, direction, and whether to have Tuna or Salmon for lunch. Meanwhile a large team of professionals in starched white uniforms tiptoes around quietly below deck, keeping everything running, filling the gas tanks, scraping off barnacles, ironing the napkins for lunch. The support staff knows what to do but they take their cues from a salty old fart who nods ever so slightly in certain directions to coordinate the whole symphony so that the programmers can abstract away everything about the yacht except speed, direction, and what they want for lunch.

Management, in a software company, is primarily responsible for creating abstractions for programmers. We build the yacht, we service the yacht, we are the yacht, but we don’t steer the yacht. Everything we do comes down to providing a non-leaky abstraction for the programmers so that they can create great code and that code can get into the hands of customers who benefit from it.

Programmers need a Subversion repository. Getting a Subversion repository means you need a network, and a server, which has to be bought, installed, backed up, and provisioned with uninterruptible power, and that server generates a lot of heat, which means it need to be in a room with an extra air conditioner, and that air conditioner needs access to the outside of the building, which means installing an 80 pound fan unit on the wall outside the building, which makes the building owners nervous, so they need to bring their engineer around, to negotiate where the air conditioner unit will go (decision: on the outside wall, up here on the 18th floor, at the most inconvenient place possible), and the building gets their lawyers involved, because we’re going to have to sign away our firstborn to be allowed to do this, and then the air conditioning installer guys show up with rigging gear that wouldn’t be out of place in a Barbie play-set, which makes our construction foreman nervous, and he doesn’t allow them to climb out of the 18th floor window in a Mattel harness made out of 1/2″ pink plastic, I swear to God it could be Disco Barbie’s belt, and somebody has to call the building agent again and see why the hell they suddenly realized, 12 weeks into a construction project, that another contract amendment is going to be needed for this goddamned air conditioner that they knew about before Christmas and they only just figured it out, and if your programmers even spend one minute thinking about this that’s one minute too many.

To the software developers on your team, this all needs to be abstracted away as typing svn commit on the command line.

That’s why you have management.

It’s for the kind of stuff that no company can avoid, but if you have your programmers worrying about it, well, management has failed, the same way as a 100 foot yacht has failed if the millionaire owner has to go down into the engine room and, um, build the engine.

You’ve got your typical company started by ex-software salesmen, where everything is Sales Sales Sales and we all exist to drive more sales. These companies can be identified in the wild because they build version 1.0 of the software (somehow) and then completely lose interest in developing new software. Their development team is starved or nonexistent because it never occurred to anyone to build version 2.0… all that management knows how to do is drive more sales.

On the other extreme you have typical software companies built by ex-programmers. These companies are harder to find because in most circumstances they keep quietly to themselves, polishing code in a garret somewhere, which nobody ever finds, and so they fade quietly into oblivion right after the Great Ruby Rewrite, their earth-changing refactoring-code code somehow unappreciated by The People.

Both of these companies can easily be wiped out by a company that’s driven by programmers and organized to put programmers in the driver’s seat, but which have an excellent abstraction that does all the hard work to convert code into products below the decks.

A programmer is most productive with a quiet private office, a great computer, unlimited beverages, an ambient temperature between 68 and 72 degrees (F), no glare on the screen, a chair that’s so comfortable you don’t feel it, an administrator that brings them their mail and orders manuals and books, a system administrator who makes the Internet as available as oxygen, a tester to find the bugs they just can’t see, a graphic designer to make their screens beautiful, a team of marketing people to make the masses want their products, a team of sales people to make sure the masses can get these products, some patient tech support saints who help customers get the product working and help the programmers understand what problems are generating the tech support calls, and about a dozen other support and administrative functions which, in a typical company, add up to about 80% of the payroll. It is not a coincidence that the Roman army had a ratio of four servants for every soldier. This was not decadence. Modern armies probably run 7:1. (Here’s something Pradeep Singh taught me today: if only 20% of your staff is programmers, and you can save 50% on salary by outsourcing programmers to India, well, how much of a competitive advantage are you really going to get out of that 10% savings?)

Management’s primary responsibility to create the illusion that a software company can be run by writing code, because that’s what programmers do. And while it would be great to have programmers who are also great at sales, graphic design, system administration, and cooking, it’s unrealistic. Like teaching a pig to sing, it wastes your time and it annoys the pig.

Microsoft does such a good job at creating this abstraction that Microsoft alumni have a notoriously hard time starting companies. They simply can’t believe how much went on below decks and they have no idea how to reproduce it.

Nobody expects Dolly Parton to know how to plug in a microphone. There’s an incredible infrastructure of managers, musicians, recording technicians, record companies, roadies, hairdressers, and publicists behind her who exist to create the abstraction that when she sings, that’s all it takes for millions of people to hear her song. All the support staff and management that make Dolly Parton possible can do their jobs best by providing the most perfect abstraction: the most perfect illusion that Dolly sings for us. It is her song. When you’re listening to her on your iPod, there’s a huge infrastructure that makes that possible, but the very best thing that infrastructure can do is disappear completely. Provide a leakproof abstraction that Dolly Parton is singing, privately, to us.

Source: Joel on Software

Meanwhile, of course, the development team has no idea that anything’s wrong. In fact, nothing is wrong. They’re right on schedule.

Don’t let this happen to you! I’m going to let you in on a little secret about those non-technical management types that will make your life a million times easier. It’s real simple. Once you know my secret, you’ll never have trouble working with non-technical managers again (unless you get into an argument over the coefficient of restitution of their golf clubs).

It’s pretty clear that programmers think in one language, and MBAs think in another. I’ve been thinking about the problem of communication in software management for a while, because it’s pretty clear to me that the power and rewards accrue to those rare individuals who know how to translate between Programmerese and MBAese.

Since I started working in the software industry, almost all the software I’ve worked on has been what might be called “speculative” software. That is, the software is not being built for a particular customer — it’s being built in hopes that zillions of people will buy it. But many software developers don’t have that luxury. They may be consultants developing a project for a single client, or they may be in-house programmers working on a complicated corporate whatsit for Accounting (or whatever it is you in-house programmers do; it’s rather mysterious to me).

Have you ever noticed that on these custom projects, the single most common cause of overruns, failures, and general miserableness always boils down to, basically, “the (insert expletive here) customer didn’t know what they wanted?”

Here are three versions of the same pathology:

1. “The damn customer kept changing his mind. First he wanted Client/Server. Then he read about XML in Delta Airlines Inflight Magazine and decided he had to have XML. Now we’re rewriting the thing to use fleets of small Lego Mindstorms Robots.”
2. “We built it exactly the way they wanted. The contract specified the whole thing down to the smallest detail. We delivered exactly what the contract said. But when we delivered it, they were crestfallen.”
3. “Our miserable sales person agreed to a fixed price contract to build what was basically unspecified, and the customer’s lawyers were sharp enough to get a clause in the contract that they don’t have to pay us until ‘acceptance by customer,’ so we had to put a team of nine developers on their project for two years and only got paid $800.”

If there’s one thing every junior consultant needs to have injected into their head with a heavy duty 2500 RPM DeWalt Drill, it’s this: Customers Don’t Know What They Want. Stop Expecting Customers to Know What They Want. It’s just never going to happen. Get over it.

Instead, assume that you’re going to have to build something anyway, and the customer is going to have to like it, but they’re going to be a little bit surprised. YOU have to do the research. YOU have to figure out a design that solves the problem that the customer has in a pleasing way.

Put yourself in their shoes. Imagine that you’ve just made $100,000,000 selling your company to Yahoo!, and you’ve decided that it’s about time to renovate your kitchen. So you hire an expert architect with instructions to make it “as cool as Will and Grace’s Kitchen.” You have no idea how to accomplish this. You don’t know that you want a Viking stove and a Subzero refrigerator — these are not words in your vocabulary. You want the architect to do something good, that’s why you hired him.

The Extreme Programming folks say that the solution to this is to get the customer in the room and involve them in the design process every step of the way, as a member of the development team. This is, I think, a bit too “extreme.” It’s as if my architect made me show up while they were designing the kitchen and asked me to provide input on every little detail. It’s boring for me, if I wanted to be an architect I would have become an architect.

Anyway, you don’t really want a customer on your team, do you? The customer-nominee is just as likely to wind up being some poor dweeb from Accounts Payable who got sent to work with the programmers because he was the slowest worker over there and they would barely notice his absence. And you’re just going to spend all your design time explaining things in words of one syllable.

Assume that your customers don’t know what they want. Design it yourself, based on your understanding of the domain. If you need to spend some time learning about the domain or if you need a domain expert to help you, that’s fine, but the design of the software is your job. If you do your domain homework and create a good UI, the customer will be pleased.

Now, I promised to tell you a secret about translating between the language of the customers (or nontechnical managers) of your software and the language of programmers.

You know how an iceberg is 90% underwater? Well, most software is like that too — there’s a pretty user interface that takes about 10% of the work, and then 90% of the programming work is under the covers. And if you take into account the fact that about half of your time is spent fixing bugs, the UI only takes 5% of the work. And if you limit yourself to the visual part of the UI, the pixels, what you would see in PowerPoint, now we’re talking less than 1%.

That’s not the secret. The secret is that People Who Aren’t Programmers Do Not Understand This.

There are some very, very important corollaries to the Iceberg Secret.

Important Corollary One. If you show a nonprogrammer a screen which has a user interface that is 90% worse, they will think that the program is 90% worse.

I learned this lesson as a consultant, when I did a demo of a major web-based project for a client’s executive team. The project was almost 100% code complete. We were still waiting for the graphic designer to choose fonts and colors and draw the cool 3-D tabs. In the meantime, we just used plain fonts and black and white, there was a bunch of ugly wasted space on the screen, basically it didn’t look very good at all. But 100% of the functionality was there and was doing some pretty amazing stuff.

What happened during the demo? The clients spent the entire meeting griping about the graphical appearance of the screen. They weren’t even talking about the UI. Just the graphical appearance. “It just doesn’t look slick,” complained their project manager. That’s all they could think about. We couldn’t get them to think about the actual functionality. Obviously fixing the graphic design took about one day. It was almost as if they thought they had hired painters.

Important Corollary Two. If you show a nonprogrammer a screen which has a user interface which is 100% beautiful, they will think the program is almost done.

People who aren’t programmers are just looking at the screen and seeing some pixels. And if the pixels look like they make up a program which does something, they think “oh, gosh, how much harder could it be to make it actually work?“

The big risk here is that if you mock up the UI first, presumably so you can get some conversations going with the customer, then everybody’s going to think you’re almost done. And then when you spend the next year working “under the covers,” so to speak, nobody will really see what you’re doing and they’ll think it’s nothing.

Important Corollary Three. The dotcom that has the cool, polished looking web site and about four web pages will get a higher valuation than the highly functional dotcom with 3700 years of archives and a default grey background.

Oh, wait, dotcoms aren’t worth anything any more. Never mind.

Important Corollary Four. When politics demands that various nontechnical managers or customers “sign off” on a project, give them several versions of the graphic design to choose from.

Vary the placement of some things, change the look and feel and fonts, move the logo and make it bigger or smaller. Let them feel important by giving them non-crucial lipstick-on-a-chicken stuff to muck around with. They can’t do much damage to your schedule here. A good interior decorator is constantly bringing their client swatches and samples and stuff to choose from. But they would never discuss dishwasher placement with the client. It goes next to the sink, no matter what the client wants. There’s no sense wasting time arguing about where the dishwasher goes, it has to go next to the sink, don’t even bring it up; let the clients get their design kicks doing some harmless thing like changing their mind 200 times about whether to use Italian Granite or Mexican Tiles or Norwegian wood butcher-block for the countertops.

Important Corollary Five. When you’re showing off, the only thing that matters is the screen shot. Make it 100% beautiful.

Don’t, for a minute, think that you can get away with asking anybody to imagine how cool this would be. Don’t think that they’re looking at the functionality. They’re not. They want to see pretty pixels.

Steve Jobs understands this. Oh boy does he understand this. Engineers at Apple have learned to do things that make for great screen shots, like the gorgeous new 1024×1024 icons in the dock, even if they waste valuable real estate. And the Linux desktop crowd goes crazy about semitransparent xterms, which make for good screenshots but are usually annoying to use. Every time Gnome or KDE announces a new release I go straight to the screenshots and say, “oh, they changed the planet from Jupiter to Saturn. Cool.” Never mind what they really did.

Remember the CEO at the beginning of this article? He was unhappy because his team had showed him great PowerPoints at the beginning — mockups, created in Photoshop, not even VB. And now that they’re actually getting stuff done under the covers, it looks like they’re not doing anything.

What can you do about this? Once you understand the Iceberg Secret, it’s easy to work with it. Understand that any demos you do in a darkened room with a projector are going to be all about pixels. If you can, build your UI in such a way that unfinished parts look unfinished. For example, use scrawls for the icons on the toolbar until the functionality is there. As you’re building your web service, you may want to consider actually leaving out features from the home page until those features are built. That way people can watch the home page go from 3 commands to 20 commands as more things get built.

More importantly, make sure you control what people think about the schedule. Provide a detailed schedule in Excel format. Every week, send out self-congratulatory email talking about how you’ve moved from 32% complete to 35% complete and are on track to ship on December 25th. Make sure that the actual facts dominate any thinking about whether the project is moving forward at the right speed. And don’t let your boss use Callaway Titanium Drivers, I don’t care how much you want him to win, the USGA has banned them and it’s just not fair.

Source: Joel on Software

First, to what extent has social media changed the way companies and entrepreneurs fundamentally express themselves to customers?

It is marketing at this point. Luckily, social media enables you to do that in a fast, free, and ubiquitous way. You really can’t spend money on social media unless you really try. Social media is really more about effort than expense.

Let’s say an entrepreneur is new to the whole social media thing. There’s a tendency to hire a consultant and formulate a plan. Is that the right approach?

No. Just dive in. Dive in to Facebook or Google+ or Twitter. Create a personal account and test the water. See what those sensibilities are, and just have at it. This is very different than the typical expert telling you that you first have to set your strategy and your goals and have this massive document and a working plan. I think that’s a mistake. It’s very difficult to create goals and strategies for something like Google+ or Facebook or Twitter if you’re not familiar with Google+, Facebook, and Twitter.

What are some of your favorite examples?

I look at the small companies that have done it really well. There are examples of bakeries that tweet when cupcakes are out, or Kogi BBQ in Los Angeles that tweet out street food locations. And 100 people show up. To me, a street food vendor driving their business like that, that’s a cool story.

You were the chief evangelist at Apple, so you know a thing or two about getting people to love your brand. But how do you promote your brand, and yourself, without becoming nauseating about it?

I think 90 percent of that battle is making sure that you truly have that great cause. What causes that “nauseation” is when you are promoting something that is crap. I don’t think Steve Jobs nauseated people when talking about how great Apple stuff was. The reason why he didn’t nauseate people is because it was true. The start of all great marketing is to have a great product.

You’re writing a book about Google+ that will come out March 8^th. So tell us, why do you love Google+ so much?

I love the quality and the interaction of the commenting. I think the comments come in faster and better than any other service. I love that you can have photos in line in a large way. I love that you can edit your posts and comments after you’ve posted them. On Twitter and Facebook, once it’s there, it’s there, and there’s no editing. I edit almost every one I do. I love the notification system on Google+. If someone mentions you, you get notified via Gmail. That’s very useful for someone like me.

Can Google+ become as big as Facebook one day?

Absolutely. No question in my mind. It’s hard to predict someone overtaking something that has a billion users. On the other hand, five years ago we said MySpace would control the world. Let me put it this way: I think it’s easier to be a search engine adding social networking than a social network adding a search engine. Google is adding this social component to search. It totally makes sense. I think it’s going to be a long time before people go to Facebook and type in “Hockey” to find the score for a game.

This all plays into search engine optimization, of course. What’s your biggest SEO tip?

My recommendation for SEO is very simple. It’s Write Good Stuff. In my mind, Google is in the business of finding good stuff. It has thousands of the smartest people in the world, spending billions of dollars to find the good stuff. All you have to do is write the good stuff; you don’t need to trick it. Let Google do its job and you do your job.

Kullanışlı arayüzü ile online olarak Visio tarzında diyagramlar hazırlayıp web tabanlı olarak yayınlayabileceğiniz, birçok dosya formatına export edebileceğiniz, diğer kullanıcılar ile paylaşabileceğiniz çok yararlı bir web sitesi. Akışlarınıza ve çizimlerinize istediğiniz yerden ulaşmak için ideal bir site. Ücretsiz hesap seçeneğinde, 25 adet diyagram oluşturmanıza izin veriyor.

screencast-o-matic.com

Online bir screen capturing uygulaması. Bilgisayarınıza yalnızca bir java applet kurarak, ekran hareketlerinizi video olarak kaydetmenize olanak veriyor. Kayıtlarınızı avi, mp4 veya flv olarak export edebilir veya direkt olarak Youtube’da yayınlayabilirsiniz. Hayat kurtaran uygulamalardan biri olarak sık kullanılan siteleriniz arasına eklemenizde fayda var.

ITIL Versiyon2 ile bilinirliği ülkemizdede ciddi oranda artan Bilişim standardizasyonu malesef güncelleme konusunda sıkıntılar yaşamıştır. Bu yazımızda ITIL Versiyon3 üzerinde duruyor ve süreçlerini ana hatları ile inceleyerek devam ediyor olacağız. Veriyon 2 içeriğine yazımızın içerisinde zaman zaman atıfta bulunurken, Versiyon 3 ile arasındaki farkları ve neden versiyon 3 ihtiyacının olduğu konusunu, Ana hatları ile bahsedeceğimiz süreçlerin herbirini, V-Model, ARCI Model yapısını ve uygulama yapısını, ISO 20000 ile arasındaki ilişkiyi ve risk analizleri ile birlikte bizler için çok önem taşıyacak olan bir takım checklister gibi ITIL spesifik tüm konuları makale dizisinde sizlere aktarıyor ve paylaşıyor olacağım.

İlk yazımızda isterseniz ITIL hakkında genel bir giriş yaparak süreç haritasına ve tasarımlara göz atıyor olalım.

ITIL – Bölüm(1)

ITIL kısaltmasını “Bilişim teknolojileri altyapı kütüphanesi” olarak açıklayabiliriz. Peki nedir bu altyapı kütüphanesi. ITIL aslında tam olarak BT Servis Yönetimi framework’ünün(Çatı-iskelet) uygulanmasını sağlamak ve kolaylaştırmak için kullanılan belgeler dizisidir. Bu özelleştirilebilir iskelet, bir Organizasyon içerisine servis yönetiminin nasıl uygulanacağını tanımlar.

İngiliz hükümetinin bir birimi olan CCTA (Central Computer and Telecomunications Agency) tarafından geliştirilmiştir ancak bu çalışma dünya üzerinde birçok özel ve yerel kurum ile birlikte akademisyenlerin de katıldığı bir çalışma ile meydana gelmiştir .

Uygulamaya dayalı bir yaklaşımı yansıtmak için Hizmet Yönetimi uygulamaları olarak bilinen ITIL v3 temel olarak birbiri ile bağlantılı 5 faz’dan oluşmaktadır; (İlerleyen makalelerimizde her bir fazı detaylı olarak açıklıyor olacağız..)

• Service Strategy
  
• Service Design
  
• Service Transition
  
• Service Operation
  
• Continual Service Improvement
  

Şekil-1: ITIL V3 Mimarisi

Birazdan bu 5 kısımdan bahsediyor olucaz ancak isterseniz biraz daha yukardan bakarak durumu yorumlamaya çalışalım.

ITIL oluşumunu sağlayan 5 başlık aslında Sevis yaşam döngümüzün oluşmasını sağlayan süreçler ile bunların dışında bu süreçleri etkileyen ve BT organizasyonumuzun dışında bulunan iç müşteri ve dış tedarikçi süreçleri servis yaşam döngümüzü etkileyen süreçlerden meydana geliyor. İsterseniz bir örnek vererek açıklamaya çalışalım; Bir Telekomunikasyon firmasının içerisindeki IT Organizasyonu olduğumuzu düşünelim ve vermiş olduğumuz hizmet çerçevesi içerisinde servis yaşam döngüsünü oluşturmuş durumdayız. Hatta bu durumu biraz daha ilerletip iç müşterimiz ile SLA(Service Level Aggrement) imzalamış olalım ve bu anlaşma içerisinde müşterimize oluşan herhangi bir problemi çözme zamanı taahhüt etmiş olalım. Diyelimki sorumlu olduğumuz yapı içerisindeki bileşenlerden biri olan mail sunucumuz herhangi bir sebepten dolayı çalışmıyor ve iç müşterimize destek veremiyoruz. Bu noktada problemi gidermek için dış kaynak kullanıyor yada herhangi bir donanım problemi ise tedarikçi üzerinden parça sağlıyoruz. Tedarikçi üzerinden gerekli olan hizmeti almak için izlemiş olduğumuz prosedürler, geçen zaman ve bu süre içerisinde mail hizmetini veremiyor olmamız yada taahhüt etmiş olduğumuz zaman diliminde problemi çözemiyor olmak nedeni ile oluşan diğer zincir reaksiyonlar aslında çerçevesi çizilmesi gereken ve yaşam döngümüzü etkileyen süreçler haline geliyor.

Yani aslında Sadece kendi IT organizasyonumuz içerisinde yer alan süreçler bizim Servis yaşam döngümüzü tamamlamamıza yeterli olmuyor. Bunların dışında kalan diğer süreçler ile entegrasyon sağlıyor olmakla ancak döngüyü tamamlayabiliyor olduğumuz sonucu oluşuyor.

Yazımızın başındada tanımını vermiş olduğumuz gibi Bir Organizasyon içerisinde Servis Yönetiminin nasıl uygulanacağını, belirlenmiş olan 5 faz ve bunların altında yeralan akış süreçleri ile az önce bahsetmiş olduğumuz dış süreçleri teker teker tanımlayarak Servis yaşam döngümüzü tamamlayabiliriz.

Şekil-1′de görmüş olduğunuz gibi mimari birbiri ile grift bir ilişiki içerisinde yer alıyor. Bir BT Organizasyonu içerisindeki BT stratejilerinin belirlenerek tasarımının yapılması sonrasında servis geçiş süreçlerinin tanımlanması ve operayon süreçlerinin tanımlanması ile servis yaşam döngüsünün büyük bir kısmını tamamlamış oluyoruz. En son fazda ise Servis kalitesinin artırılabilmesi için gereken raporlama, ölçümleme ve iyileştirme işlemlerinin yapılacağı süreçlerin diğer süreçler ile entegre edilmesi ile süreç haritamızı tamamlamış oluyoruz.

Süreçlerin tasarlanabilmesi, uygulanabilmesi,entegre edilebilmesi ve yönetilebilmesi noktasında birtakım ana roller’e ihtiyaç duyulmuş ve ilgili roller tanımlanmıştır. Bu roller organizasyon süreçlerinin analiz edilmesinden sonra deploy edilmelidir. Kısaca bu görevlere bakacak olursak;

• Service Owner : Bir servisin tasarımı, entegrasyonu, performansı, iyileştirilmesi ve yönetilmesini kapsar.
• Process Owner : Bir servisin tasarımı, entegrasyonu, performansı, iyileştirilmesi ve yönetilmesini kapsar.
• Product Manager : İlgili servis gruplarının performansı, iyileştirilmesi ve yönetilmesini kapsar.
• Service Manager : Oluşum içerisinde yeralan tüm servislerin performansı, iyileştirilmesi ve yönetilmesini kapsar.

Buna paralel olarak iş Modellemesi üzerinden sorumluluk ve rol tanımlarına yukardan baktığımızda Şekil-2 de görünün sorumluluk yapısı hiyerarşik olarak görülüyor.

Resim-2

Süreçlerin tasarımı, iyileştirilmesi, geliştirilmesi ve yönetilmesi için kullanılmakta olan rollerimizin dışında özellikle servis geçişi ve operasyon süreçleri esnasında tanımlanması gereken bir takım rollerimiz olucak. ARCI Model diye adlandırılan bir matrix yardımı ile görev tanımları yerleştiriliyor olucağız ki bu modelleme yapısı üzerinde ayrı bir yazımızda duracağız.

Resim-3

• Service Strategy (Hizmet Strateji)
  

Servis Yönetiminin uygulanması,geliştirilmesi ve tasarlanması konusunda rehber niteliğindedir. Bu konuda BT Organizasyonlarının müşterilerine farklı hizmetler sunmasını ve operasyonel etkinliğini artırmasını amaçlar.

Süreçler;

• Service Portfolio Management : Hizmet Portföy Yönetimi süreci, Hizmet Portföyü hizmetlerine ilişkin bilgi yönetimi ile ilgilenir
• Demand Mamagement : Talep süreçleri Yönetimi, müşteri taleplerini anlama ve etkileme ile ilgilenir.
• IT Financial Management : BT Finans yönetimi, “Maliyetleri yönetmeyi ve anlamayı ” ve Mali anlamda hizmetler ile ilgili fırsatlarla ilgilenir.

Roller ve Sorumluluklar;

• Business Relationship Manager (BRM): Müşterisinin iş gerekliliklerini ve onların müşterisinin ihtiyaçlarının belirlenmesi noktasında güçlü ilişkiler kurar. Müşterisi adına verimli sonuçlar çıkarabilme noktasında PM ile yakın çalışır.
• Product Manager (PM) : Servis Yaşam Döngüsündeki servislerin yönetilmesi ve geliştirilmesinden sorumludur.
• Chief Sourcing Officier (CSO) : CIO(Chief Information Officier) ile yakın işbirliği içerisinde kaynak stratejisinin geliştirilmesi ve kaynakların yönlendirilmesi ve yönetilmesinden sorumludur.

• Service Design (Hizmet Tasarım)
  

Servis Tasarımı, iş gereksinimleri değişimi sürecinde önemli bir eleman ve Genel servis yaşam döngüsü içerisinde önemli bir katmandır.

Özelleştirilebilir ve Yenilikçi BT Hizmetleri tasarımı, süreçler, politikalar ve belgeler de dahil olmak üzere mevcutta kabul edilmiş ve gelecekteki iş gereksinimlerini karşılamak için oluşturulan mimarilerdir.

Başarılı bir tasarımın yapılabilmesi için 4P (People,Product,Processes, Partners) tasarımının doğru yapılmasına bağlıdır.

Service Design Package (SDP); Servis Yaşam döngüsünün her bir aşamasındaki gereklilikleri ve bir BT Servisinin bütün yönlerini tanımlar. Bir SDP, her yeni servis, major değişiklik yada bir servisin kaldırılması durumunda yeniden üretilir.

Süreçler;

• Service Catalogue Management (SCM): Hizmet kataloğu,
  Servis Destek sağlayıcısı tarafından BT servisleri hakkındaki bilgilerin merkezi bilgi kaynağı üzerinden iletiminden sorumludur.
• Service Level Management (SLM): Spesifik hizmetler ile ilişikilendirilmiş garanti seviyeleri, Hizmet sağlayıcı ile ilgili performans seviyeleri, müşteri ile yapılan anlaşmanın yönetilmesi ve güvenliği,fiyatlandırılması konularından sorumludur.

SLM süreçleri içerisinde SLA(Service Level Aggrement), OLA(Operational Level Aggrement) bulunur ve SIP (Service Improvement Plan) ile Service Quality Plan’ın üretilmesini sağlar.

• Capacity Management : Kapasite Yönetimi servis ömrü boyunca iş, hizmet ve bileşen kapasite yönetimi içerir. Kapasite yönetiminin temel başarı faktörü, tasarım aşamasında göz önünde bulundurulmasıdır.

Tüm Kapasite ve performans tabanlı sorunların yönetimine ve hizmet ve kaynaklara ilişkin iş taleplerinin uyuşmasına odaklanır.

3 Ana faaliyet sözkonusudur;

• Business Capacity Management
• Service Capacity Management
• Component Capacity Management

• Availability Management : Kullanılabilirlik Yönetimi, kurgulanan SLA(Servis seviyesi Anlaşması) içerisindeki kullanılabilirlik gereksinimlerinin ve yönetiminin başarısı ile ilgilidir.

Kullanılabilirlik, Gerektiğinde sistem, hizmet yada Configuration-Item fonksiyonu gerçekleştirme yeteneği olarak tanımlanır.

• IT Service Continuity Management (ITSCM) : Herhangi bir felaket olayı esnasında BT hizmet ve servisleri için planlama ve risk yönetimi ile ilgilenir.

BIA (Business Impact Analysis) ve MOR(Management of Risk) tekniklerini kullanarak iş sürekliliği yönetiminde büyük çaba harcar.

• Information Security Management (ISM) : Servisler de dahil olmak üzere tüm BT envanterlerini gelebilecek tehditlere karşı korumak ile ilgilenen süreçtir.

5 temel niteliğin korunması üzerinde duruluyor;

• Confidentiality
• Integrity
• Availability
• Authenticity
• Non-Repudiation

• Supplier Management : Tedarikçi Yönetimi aslında Service Level Management((SLM)- Hizmet seviyesi yönetimi))’ne çok benzer bir rol oynar ve Hizmet tasarımı içerisinde kritik bir rol alır. İç tedarikçi ve müşterilerden daha çok dış tedarikçiler ile ilgilenir.

Özellikle son yıllarda oranı artan dış tedarikçi ile yapılan anlaşmalardan da anlaşılabileceği üzere kendi müşterilerine daha iyi hizmet verebilme noktasında dış tedarikçilere olan bağımlılık artmıştır.

Roller ve Sorumluluklar;

• Service Design Manager : Hizmetler ve süreçler noktasında oluşturulan tasarım ve genel koordinasyon dan sorumludur.
• IT Designer /Mimar : Planlama, tasarım, strateji, mimari, tasarım için gereken teknolojiler ve genel koordinasyondan sorumludur.
• Service Catalogue Manager : Doğru bir Hizmet kataloğunun oluşması noktasındaki üretim, geliştirme ve bakımdan sorumludur.
• Service Level Manager : Hizmet Seviyesi kalitesinin karşılanabilmesi ve kabul edilebilir olmasından sorumludur.
• Availability Manager : Tüm Servislerin kabul edilebilir hedeflerine ulaşmasından sorumludur.
• IT Service Continuity Manager : İş ihtiyaçları, gereklilikleri ve zaman çizelgelerine uygun olarak tüm servislerin iyileştirilmesinden sorumludur.
• Capacity Manager : BT Kapasitesinin bügünkü ve gelecekteki iş talepleri ile uyumlu olmasından sorumludur.
• Security Manager : Belirlenmiş iş güvenliği politika riskleri, etkileri ve gereksinimleri ile BT güvenliğinin uyumlu olmasından sorumludur.
• Supplier Manager : BT Tedarikçileri,sözleşmeleri ve anlaşmaların iş ihtiyaçlarına uyumlu olması ve değerinden sorumludur.

• Service Transition (Hizmet Geçiş)
  

Hizmet geçiş rolü, Operasyonel süreçte kullanılmak üzere iş gerekliliklerini iletir.

Hizmet geçişi, Servis tasarım aşamasından Hizmet tasarım paketini alması ile başlar ve Operasyonel aşamaya devam eden operasyon ve hizmet desteği için gerekli tüm bilgileri ve elemanaları teslim eder.

İş Koşulları, gereksinimleri yada varsayımlar tasarım sürecinden sonra değişime uğradıysa, Hizmet geçiş aşamasında gerekli hizmeti sunmak için bir takım değişiklikler gerekebilir. Unutulmaması gereken en önemli nokta Hizmet Geçişi sadece uygulamalarla ve/veya normal şartlar altında nasıl kullanıldığı ile değil hizmetlerin tüm yönleri ile uygulanmasından sorumludur.

Süreç içerisinde bilinmesi gereken V-Model yapısını ve RFC,CI,CMS,CAB,ECAB gibi tanımları ve içeriği hakkındaki detayları, süreci daha derin incelediğimiz makalenin içinde bulabilirsiniz..

Süreçler;

• Change Management : Değişiklik Yönetimi, ilgili değişikliklerin değerlendirilmesi, kayıt edilmesi, önceliklendirilmesi, planlanması, test edilmesi, uygulanması, dökümante edilmesi ve düzenli şekilde gözden geçirilmesini sağlar.
  

Bir Hizmet değişikliği, ek, yetki , planlama yada desteklenen hizmet yada hizmet bileşeni gibi üzerinde olabilecek değişiklik ve ilgili dökümanlarla ilişkilendirilmesidir.

• Service Asset and Configuration Management (SACM) : Bir Organizasyonun altyapısını oluşturan ilişkileri, tüm varlıkların kontrolünü ve bilgilerin doğruluğunu sağlar. Yapılandırma öğeleri (Configuration Item(CI)) ve hizmet varlıkları’nın belirlenmesi, kontrol edilmesi ve hesaplanması ile birlikte Servis yaşam döngüsü boyunca kendi bütünlüğünü sağlamayı ve korumayı amaç edinir.
  
• Knowledge Management : Bilgi Yönetimi, işin gerektirdiği hizmet desteğini, doğru kişiye doğru bilgi ile doğru zamanda iletmekten sorumludur.
  

Roller ve Sorumluluklar;

Bir Organizasyon içerisinde hizmete geçiş sunan personel; etkin, verimli ve va olan çeşitli seçenekleri sunmak için organize edilmelidir.

Tipik bir organizasyon içerisinde bu roller tahmin ile değil ayrı bir grup olarak düşünülür. Bu Daha fazla beceriye ve deneyime sahip Aynı insanlar Birden fazla yaşam döngüsü aşamalarına dahil olabilir anlamına gelir.

• Service Operation (Hizmet Operasyon)
  

Hizmet Operasyonu, Kullanıcılarına ve Müşterilerine belirlenmiş hizmet seviyesini sağlayacak olan uygulama yönetimi, teknoloji ve altyapı hizmet desteği sunar.

Bu hizmetler sadece servis yaşam döngüsünün bu aşamasında işe gerçek değerini verir. Hizmet yaşam döngüsü, Hizmet operasyonu aşamasında, kabul edilen parametreler dahilinde faaliyet sağlamakla ilgilenir. Herhangi bir hizmet kesintisi meydana geldiğinde, Servis operasyonu olabildiğince çabuk şekilde servisleri geri yüklüyerek iş etkisini en aza indirgiyor.

Bu sürecin fokus olduğu birtakım parametreler olan “Reactive-Proactive”, “Internal-External”, “Cost-Quality”, “Stability- Flexibility” arasında denge sağlamak durumundadır. Eğer bu dengeyi kuramazsa Hizmet Operasyonu kötü olarak görünüyor olucaktır.

En önemli kısımlardan biri ise operasyon esnasında olan iletişim dir ver her ne olursa olsun iletişimin doğru algılanması kurulması gerekir. Bu ilişkiler;

• BT Hizmet sağlayıcı ile kullanıcı arasındaki iletişim..
• BT Hizmet sağlayıcı ile Müşteri arasındaki iletişim..
• BT Hizmet sağlayıcı içerisinde yer alan farklı süreçler, fonksiyonlar ve takımlar arasındaki iletişim..
• BT Hizmet sağlayıcı ile tedarikçileri arasındaki iletişim..

Süreçler;

• Incident Management : Sorun Yönetimi, olası herhangi bir sorunun bildirilmesi ile gelen isteğin işe etkisinin en aza indirgenmesi noktasında Çoğunlukla servislerin hızlı şekilde restorasyonu sağlar. Fakat bazı vakalardan durum sorun yönetiminden çıkarak yardım masası tarafından sahiplenilir ve uygulanır.

Temel aktiviteler;

• Detection
• Logging
• Classification
• Prioritization
• Investigation and Initial Diagnosis
• Escalation
• Resolution and Recovery
• Closure

• Problem Management : Problem yönetimi,Vaka’ya sebep olan oluşumun içerisindeki hata yada kusuru düzeltmek ve tanımlamak ile ilgilenir. Sorunların azalmasına ve engellenmesini yardımcı olur ve iki alt süreçten oluşur;
  • Reactive Problem Management : Genellikle Sorun yönetimi süreci tarafından yönlendirilen problemlerin aşılması sürecidir.
  • Proactive Problem Management : Hata-Sorun isteği gelmeden önce servisler ve altyapı üzerinde Proaktif olarak iyileştirme aramaları yapan süreçtir.
    
• Event Management : Olay Yönetimi, Altyapı üzerinde oluşan olayların tespiti ve uygun müdahale eylemlerinin seçimi ile ilgilenir. Olayların erken tespit ediliyor olması, etkilenen kullanıcılar tarafından gelecek hata sayılarının düşmesine neden olacağı gibi, Sorun yönetimi sürecinin performansını artırarak olayların azalıtması sağlanmış olur. 3 Tip olay vardır;
  • Informational
  • Warning
  • Exception
• Access Management : Erişim Yönetimi kimlik ve haklar ile ilgilenir. Bu süreç kimlik ve yetki doğrulama, hizmetlere erişim verme, işlem günlüğü, erişim izleme-kaldırma yada durum veya rollerin haklarını değiştirmeyi içerir.

Erişim Yönetimi, gizlilik, kullanılabilirlik ve veri bütünlüğünü yönetmenize yardımcı olur. Yetkili olmayan kullanıcıların erişimlerini engellerken, erişim yetkisi olan kullanıcıların bir servise yada servis grubuna erişimini sağlar.

• Service Request Fulfillment : Hata yönetimine ddahil edilemiyecek ortak kullanıcı istekleri olarak adlandırılmaktadır. Yeni bir ekipman yada bir eğitim isteği bu başlığın altında değerlendirilir. Özellikle belirli periyotlarda kullanıcılar tarafından yapılmakta olan bir isteğin cevaplandırılması için idealdir.

Bütün istekler kayıt edilmeli ve izlenilmelidir. Bu süreç içerisinde aynı zamanda dikkat edilmesi gereken en önemli konu ise isteğin cevaplanmadan önce onay sürecine sokulmasıdır.

• Continual Service Improvement (Hizmet İyileştirme Sürekliliği)
  

Değişen iş ihtiyaçlarına göre fonksiyonların, süreçlerin ve hizmetlerin yeniden uyumlu hale getirilmesi sürecidir. Aynı zamanda Genel Hizmet yönetimi içerisindeki kalite yönetim yöntemleri uygulama tutarlığı ile ilgilenir.

ITIL içerisinde “Ölçü (Measurement)” kritik bir rol almaktadır. Hizmet iyileştirme sürekliliğinin bi parçası, aynı zamanda Hizmet seviyesi Yönetiminin ve tüm süreçlerin önemli bir parçasıdır. Ölçümleri burada 4 temel amaç için kullanılabilir;

• Doğrulamak (Justify)
• Direkt (Direct)
• Müdahale (Intervenne)
• Onaylamak (Validate)

(Bir sonraki makalemiz içerisinde metodlarından bahesediyor ve ölçümlemedeki kritik noktalardan bahsediyor olacağız.)

7 adımda iyileştirme süreci ölçümleme ile Hizmet performansının düzeltilmesi ve iyileştirilmesini sağlıyor. İsterseniz kısaca bu adımların ne olduğuna bakıyor olalım;

• Karar à Ne Ölçülmelidir
• Karar à Ne Ölçülebilir
• Veri Toplama
• Veri İşleme
• Veri Analizi
• Veri Kullanma ve sunma
• Düzeltici Eylem (Aksiyon) uygulama

Hizmet Seviyesi Yönetimi (SLM) aynı zamanda Servis Tasarım yaşam döngüsü aşamasının içerisindeki süreçlerden birisidir. Bir çok aktivite ve nesne Hizmet iyileştirme sürekliliği ile ortaktır. Özellikle her iki Hizmet seviyesi yönetimi ve iyileştirme sürekliliği düzenli ölçüm, servislerin gözden geçirilmesini ve servis yönetim başarımının diğer yönlerini vurgulamaktadır.

Service Improvement Program (SIP); Hizmet İyileştirme Planı yada Hizmet İyileştirme Programı, Hizmet iyileştirme sürekliliğinin bir parçası olarak yada Hizmet seviyesi yönetimi sürecinin bir parçası olarak yürütülen periyodik hizmet değerlendirmesinin birincil çıktısıdır.

ITIL yapısını oluşturan herbir parça birbiri ile grift ilişki halindedir ve süreçlerin iç içe geçtiği birçok noktada genel yorum kullanmamız gerekir. Bu yazımızda olabildiğince detaylara girmeden Ana hatları ile bir resim çizmeye çalıştım. Bundan sonraki yazılarımız içerisinde spesifik bir konu ve detayları üzerinde durarak ilerliyor olacağız. Bilgilerin yararlı olduğunu umut ediyorum.

Bu konuyla ilgili sorularınızı http://forum.mshowto.org linkini kullanarak ulaşacağınız forum sayfamızda sorabilirsiniz.

Referanslar

http://www.best-management-practice.com

http://wiki.en.it-processmaps.com

An SRS is written in precise, clear and plain language so that it can be reviewed by a business analyst or customer representative with minimal technical expertise. However it also contains analytical models (use case diagrams, entity relationship diagrams, data dictionary etc.) which can be used for the detailed design and the development of the software system. SRS is one of the most critical pieces of software development since it acts as the bridge betweens the software developers and business analysts. An incomplete or incorrect SRS can have disastrous effects on a software project.

In this article I explain the major sections of a typical Software Requirement Specification document. I also provide a generic SRS template which can be customized for your project needs.

What is the need for an SRS document?

Software Requirements Specification is usually the first deliverable for any software project. As they say, first impression is the best impression!, and you should ensure that even the first draft of an SRS is of high quality.

The benefits of a good SRS are,

• A contract between the customer and the software vendor – A good SRS document specifies all the features required in the final system including technical requirements and interface requirements. SRS document is used by the customer to determine whether the software vendor has provided all the features in the delivered software system. To the Software vendor it provides a solid foundation to fix the scope of the software system.
• Enables costing and pricing of the project – A well defined SRS enables software developers to accurately estimate the amount of effort required to build the software product. Function point analysis and SMC are some the techniques adopted for estimating effort.
• Input for detailed design – A good SRS enables experienced developers to convert the requirements directly to a technical design. For example, a well defined data dictionary can be easily converted to a database specification.
• Management of customer expectations – Since SRS precisely defines project scope, it ensures that customer expectations don’t change during software development. If they do, SRS can be modified and costing/pricing can be done again on the changes required.

What are the contents of an effective SRS document?

There is no single precise template for writing good Software Requirement Specifications. The contents of an SRS document depends on the software product being developed and also on the expertise of the people doing the requirement elicitation. Different business/technology domains in a company usually have their own customized version of SRS template. Still a good Software Requirement Specification (SRS) usually contains project scope section, functional requirements, requirement analysis models, external interface requirements and non functional requirements. Each of these are explained below.

Scope of the project/ Product vision

One of the most important items in the requirements specification is the precise scope definition of the project. Accuracy of this is important since SRS is also used for estimation and costing. This section should include a brief overview of the project and should also indicate the goals of the project including its benefits. Sometimes it is better to separate the project scope into a separate document.

If the project is for the development of a product, product vision defines the scope and the target user base of the product.

Functional Requirements

Functional requirements specify the business requirements of the project in detail. Usually business requirements are specified in terms of the actions that user performs on the software system. This is known as the use case model. But not all requirements need to be specified as use cases. Functional requirements should contain a combination of use cases and plain textual description of system features. System features are specified at a higher level and use cases attempt to translate into user actions.

Again there is no fixed format for use case description, but it usually contains the following information,

• Use case diagram – For a small systems, a single diagram can be used to depict all the use cases in the system.
• List of actors and their details – This identifies the various types of users interacting with the software system.
• Use case description – Purpose of the use case and how and when it is invoked by the user. This should also include an identifier for easy reference.
• Preconditions – List of system states/conditions that must be true for the successful execution of the use case. This section is optional and could be easily incorporated into the basic steps section.
• Basic steps – These indicates the various fine grained steps required for the execution of the use case.
• Alternate steps – These indicate alternate events of the use case being described.
• Business validations/rules – These indicates various types of input validations or business rules required in the use case being described.
• Post conditions – Indicates the results of the use case. Please note that this section is optional and could be incorporated into the basic steps section.

To ensure that all the business requirements are addressed in the final software product, a traceability matrix document is used. Traceability matrix tracks each requirement through various phases of software development (detailed design, unit test plans, system testing plans, user acceptance test plans and code components). This requires that every requirement in the SRS should be identifiable by a unique number or tag.

For software projects where majority of features are available as user interfaces, it is better to complement this section with screen prototypes. These user interfaces can change during detailed design, but having a draft version of user interface in the requirements document helps a lot in communicating business requirements. However some customers insist on having finalized user interfaces in the requirements specification document.

Requirement Analysis Models

Once the overall use cases in the system are identified in requirements elicitation, requirement analysis models can be developed to drill down to specifics of each requirement. For example, a use case such as “Add customer” may not specify all the customer details that needs to be captured by the system. This is usually specified in the data dictionary model and also in the screen prototype.

Requirement Analysis models act as the bridge between functional requirements and the detailed design of the software system. For example, Use cases lead to user interface design, data dictionary and entity relationship diagrams are used for designing database schema and class diagrams.

Following are some of the widely used requirement analysis models,

Entity Relationship Diagrams

Entity relationship model diagram (ERD) is a conceptual representation of the data in a software system. During detail design this model is mapped in to the physical database model. There are different diagramming conventions available for creating ER diagrams. Following is a sample ERD in Crow’s foot notation (this is taken from the ERD of a course registration Web application requirements),

This diagram indicates that there is one and only one instructor for a course and an instructor can have one or more courses. The relationship is captured as instructor “teaches” course.

Data Dictionary

Data dictionary in a requirements document is an extension of the entity relationship diagrams. Which ER diagrams specify system entities and their relationships, a data dictionary lists all the attributes pertaining to each of those entities.

In a data dictionary, each attribute of the entity data in system is analyzed in detail including type of attribute, whether it is optional and a brief description of the attribute. Please see the sample SRS template section for more details.

In addition to the above models, sometimes it is useful to develop state transition diagrams and data flow diagrams. To describe a complex process flow or a workflow in the application, process flow diagrams or flowcharts can be used.

External Interface Requirements

It is very rare that we have a standalone software system. Usually a software system interacts with a number of external applications for data input and output. For example, an e-business application usually needs to be integrated to an external payment gateway. All the external interface requirements are detailed in this section. The important thing to document here are the entities that are passed across the external interfaces.

Non Functional Requirements

Non functional or technical requirements specify how the software system should operate. In contrast functional requirements specify what a software system should do. Some of the non functional requirements are derived from the functional requirements. Non functional requirements captured include performance requirements, application scalability, application security, maintainability, usability, availability, logging and auditing, data migration requirements, multi lingual support etc. Please note that only a subset of the list are applicable for a specific project.

Importance of a good SRS template

A good SRS template ensures that all important information required in a Software Requirement Specification is captured during requirement elicitation. Following is the table of contents taken from the SRS template linked below.

Contents of Software Requirements Specification (SRS) Template

Download Sample SRS template

Click here to download a generic software requirement specification template. Please note that this SRS template is written in open office RTF format(A PDF version is available here). Not all sections are mandatory and you can easily customize this template for your project requirements.

• Download SRS template in Open Office format
• Download SRS template in PDF format
• Download SRS template in Microsoft Office format

Further Reading / References

• Crow’s foot notation for ER diagrams

Recommended Books

• Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle. – This is an excellent book on requirements gathering. It also covers all the major requirements modeling techniques. Appendix of this book contains a number of good requirements document samples including vision and scope document, use cases and business rules. Highly recommended.
• Writing Effective Use Cases – This is an excellent book that can help you in mastering the art of writing effective use cases. Written by Alistair Cockburn almost a decade ago this is a must have book for a business analyst. It will help you in steering clear of a lot of mistakes during use case preparation.

Final Thought

Always remember that the primary purpose of an SRS document is to ensure proper communication between people involved in the development of a software product. So the SRS template acts just as a guideline and you can add any additional information that helps this communication.

Source : www.jaysonjc.com