#sandton city at sunrise! I love this city. #architecture #building #TagsForLikes #architexture #city #buildings #skyscraper #urban #design #minimal #cities #town #street #art #arts #architecturelovers #abstract #lines #instagood #beautiful #archilovers #lookingup #style #archidaily #composition #geometry #perspective #geometric #pattern
Another requirement we’ve been looking for lately is the ability to resolve or close multiple incidents from the list view.
This might seem like a simple task, creating a basic UI Action of a list choice type, and do a simple
current.state = 6;
And that’d do fine, for all…
From the sound desk #sandton #church #southAfrica #God #Jesus #love
Industry speculation suggests that FNB is in discussions with Cell C to become a mobile virtual network operator, and launch services competing against Vodacom, MTN and Telkom Mobile.
Two independent sources have informed MyBroadband that FNB and Cell C are in discussions about an MVNO agreement, and that a positive outcome is likely.
If FNB becomes an MVNO, as the rumours suggest, it will join Virgin Mobile in offering cellular services using its own SIM cards and Cell C’s network.
FNB is already offering its banking clients discounted mobile devices, including tablets and smartphones, and by becoming an MVNO it can ship these devices with its own FNB SIMs.
An MVNO agreement can also help the bank to benefit further from its position as one of the biggest airtime distributors and bulk SMS users in South Africa.
FNB and Cell C comment on MVNO rumours
Virginia Magapatona, head of corporate communications at FNB, sidestepped questions about the bank’s MVNO ambitions and the rumoured discussions with Cell C.
Magapatona did, however, hint that FNB is planning more mobile products. “We continue to hold discussions with various operators on various matters and will only be in a position to formally announce any new features once launched,” she said.
Cell C’s executive head of communications, Karin Fourie said that the operator is currently in talks with various potential MVNOs.
However, because these talks are confidential, Fourie said that Cell C cannot provide any specifics about potential MVNO deals.
More on FNB and Cell C
A Competition Commission settlement will force Telkom reduce the prices of wholesale services, including “access to ADSL lines via the IP Connect service”
The Competition Commission and Telkom have reached a settlement agreement to resolve a series of complaints lodged against Telkom from 2005 to 2007 by various companies, including the Internet Service Providers’ Association (ISPA),Internet Solutions, Multichoice, and Verizon.
The settlement package includes an admission of guilt by Telkom, a R200-million penalty, a functional separation between Telkom’s retail and wholesale divisions, a transparent transfer pricing programme, and wholesale and retail pricing commitments for the next five years estimated to yield R875m savings to customers.
ISPA welcomed the settlement, saying that the settlement addresses the reality that Telkom is both an active competitor and the provider of the basic infrastructure and services that the whole industry relies upon.
“This is far more constructive than simply giving Telkom a fine, and consumers are set to benefit, not just the complainants,” said Dominic Cull, ISPA’s regulatory advisor.
Cull warned, however, that the effectiveness of the settlement will only be able to be judged through its implementation.
“ISPA will be watching to ensure that it is enforced adequately and that the monitoring of Telkom’s subsequent conduct is effective,” said Cull.
Forced price reductions
As part of the Competition Commission settlement, Telkom will reduce the prices of wholesale services implicated in the complaint and used by ISPs to deliver their IP VPN and Internet access services over the 2014, 2015 and 2016 financial years.
The price reductions will apply to undersea cable international lines, national high bandwidth transmission lines, access to ADSL lines via the IP Connect service and Diginet leased line access.
It will also apply to retail products, including Telkom’s VPN Supreme and Internet Access.
“The price reductions are weighted more heavily in favour of wholesale services (at least 70% wholesale) to bring about a more competitive market and will amount to an estimated R875m savings to the market,” the Competition Commission said.
“Telkom will also ensure that any price reductions are not reversed in the 2017 and 2018 financial years.”
MWEB ISP CEO Derek Hershaw
MWEB ISP CEO Derek Hershaw said that while you can’t expect Telkom to come “absolutely clean”, there must be enough transparency for the rest of the industry to feel comfortable that the playing fields have been levelled.
“That covers a wide range of issues including pricing, internal accounting and access to customer information,” said Hershaw.
When it comes to where Telkom should cut prices, Hershaw said that there is enough competition already as far as international bandwidth is concerned, and national bandwidth is not far off.
“In a year or two there will be enough competition in the national bandwidth market to force Telkom to reduce pricing without requiring any external intervention,” said Hershaw.
“The focus has to be on reducing the cost of IPC [IP Connect], and the cost of last mile access to the consumer – so either a reduction in ADSL line rental charges or the introduction of a naked ADSL, or both.”
Afrihost CEO Gian Visser
“This is, by far, the biggest input cost we pay to bring ADSL to our clients. It is still significantly more expensive than international, undersea cable connectivity costs and this should change,” said Visser.
“If Telkom were to cut these costs by 70% I guarantee you that the ADSL landscape in this country would be radically altered.”
Visser said that if he was the CEO of Telkom and could do only one thing to re-invigorate ADSL, he would simply cut the wholesale IPC costs to the bone.
“The second thing I would love to see is a significant drop in the monthly ADSL line rental that clients pay – including the ability for a client to choose Naked ADSL,” said Visser.
“This would also decrease the input costs for consumers and encourage people to adopt ADSL as their preferred broadband connection.”
Visser also called for a proper separation of wholesale and retail within Telkom. “That means Telkom Wholesale should invoice Telkom Retail for individual lines and bandwidth, just like they do to the ISPs and large enterprises,” said Visser.
Visser also asked for a proper audit of Telkom Retail’s books to see that they are in fact being charged wholesale rates and selling at a profit.
Cybersmart CEO Laurie Fialkov
“There has supposedly been a functional separation between wholesale and retail in Telkom for years, so I am really not sure if this changes much,” said Fialkov.
“A functional separation is of little consequence if, as wholesalers, we are unable to match Telkom’s retail pricing,” said Fialkov. “Telkom should also not be allowed to bundle services with retail where there is no wholesale offering.”
Fialkov said that Telkom’s 3G and ADSL bundled products, where there is no Telkom Mobile wholesale product available, is one such example.
When it comes to lower prices, Fialkov said that IPC is still the biggest input cost in providing an ADSL service, followed by the cost of local bandwidth. “Any reduction in IPC costs would be most welcome,” said Fialkov.
Fialkov explained that it currently costs them more to get to another data centre 180m away, than what it costs them to connect to London via undersea cables. “A reduction in local bandwidth costs would therefore be second on the list,” said Fialkov.
Internet Solutions legal manager, Marc Furman
“The settlement appears to put in place the necessary elements of functional separation between the wholesale and retail divisions of Telkom,” said Furman.
“The elements of this agreement which give effect to functional separation are the requirement for Telkom to create and apply a Code Of Conduct to Telkom Wholesale with respect to its relationship with Telkom Retail and its wholesale customers.”
Furman said that there is also the requirement that Telkom put in place a transfer price policy which governs how Telkom Wholesale prices services internally to Telkom Retail.
“The requirement that Telkom Retail keep separate accounts which reflect such internal pricing as well as complete transparency in this regard is also an important aspect of the functional separation.”
Furman said that the above terms are critical components of a successful settlement but equally important are the mechanisms which will be used to enforce the above rules.
“The settlement agreement appears to make provision for this by way of thorough external and internal Telkom audits over the next five years,” said Furman.
“The success of this agreement will be determined by the enforcement of these rules and the Commission’s commitment to ensuring Telkom’s adherence to them over the years ahead.”
“As far as what IS would look to achieve with respect to price reductions from Telkom, the all-important requirement is that products and services in the wholesale space are reduced as soon as possible to bring about complete parity between Telkom Retail and Telkom’s other wholesale customers. A reduction in retail pricing would also be welcomed by IS,” said Furman.
Vox Telecom Chief Commercial Officer Murray Steyn
Vox Telecom Chief Commercial Officer Murray Steyn said that they would like to see is true separation between Telkom wholesale and Telkom retail, not merely paying lip service to it as they have in the past.
“Telkom have always claimed to have separated wholesale from retail, but in admitting to anticompetitive practices they have confirmed what the rest of the industry has been saying for a long time, that the so-called segregation between the two has been a sham,” said Steyn.
“Not only that, but it has hampered the development of the industry, at the expense of Telkom’s competitors and ultimately, the consumer.”
Speaking about the promised price cuts, Steyn said that previous drops in these wholesale prices have resulted in significant and immediate drops in the price that consumers pay for those services.
“This is because the Licensees that pay to access the Telkom network operate in a competitive environment with each other, whereas Telkom has a monopoly over its network, and there is no transparency of the prices that it provides to its retail operation,” said Steyn.
“It is not clear exactly how this functional separation of wholesale from retail is going to happen, but if done properly and transparently, one thing is certain; if wholesale prices drop, retail prices to end users will drop as well.”
More on Telkom and the Competition Commission
TeamViewer and XBMC: Dealing With The Sponsored Session Popup
Wow it is annoying when you end a remote session with Teamviewer, and the receiving client gets the infamous sponsored pop up ruining the view.
I do not have an automated solution sadly. But I have a workaround. My wife is ill and often bound to her bed so I find Teamviewer very useful to help her from my office. Especially around XBMC.
The session POPUP is so annoying when watching XBMC, especially when my wife is not feeling too good and she cannot move to close it after I have worked on the Mac. Here is what I do after closing a session on Teamviewer and XBMC is running on top.:
I SSH into the MAC and type
This gives me a list of processes running and their PID’s. There are two Teamviewer processes. The one with teamviewer_s must not be tampered with. Get the PID of the other teamviewer processs. Then I kill it with this:
sudo kill insertPIDhere
I enter in my Mac’s root password and teamviewer and the pop up disappear and my wife can see XBMC in the front again.
If i need to run a Teamviewer session again i simply SSH into the Mac and type
open -a teamviewer
I have Teamviewer automatically sign into my profile so that I can teamview from my office to home.
It would be so great to have this done automatically.
Most Service Desk staff (those performing Classification and Initial Support) will not know the cause of an Incident until the call is closed. So how can they identify the problem? The answer is that they can’t and don’t have to…
How do you implement Incident classification? This is perhaps one of the most common questions that comes up when trying to establish Incident Management based on the IT Infrastructure Library® (ITIL ®). According to ITIL, the goal of Incident classification and Initial support is to:
- Specify the service with which the Incident is related
- Associate the incident with a Service Level Agreement (SLA )
- Identify the priority based upon the business impact
- Define what questions should be asked or information checked
- Determine a primary reporting matrix for management information
- Identify a relationship to match against Known Errors or solutions
- Select and/or define the best specialist or group to handle the Incident
Thus, Incident classification exists primarily to classify incidents in order to provide initial support. Initial support means proper analysis, evaluation and if required, routing. Classification is neither to determine root cause nor technical causes of the incident.
This single observation—that Incident classification is not to identify problems but rather guide workflow – causes a tremendous amount of angst. The problem compounds when vendors promote classification schemes designed for knowledgeable technicians and not service desk agents.
The basics of classification have been presented in previous articles (see below for links). In this article I want to explore the issues behind the actual classification hierarchy itself, which is where most practitioners experience problems. Based on my experience helping to design classification systems, the following compares and contrasts two different classification schemes, and provides a model that truly reflects ITIL practices.
Door Number 1 – Category/Type/Item
Many IT Service Management tools that offer Incident management automation use a simple Category/Type/Item (CTI) for classification. CTI is a three-tiered approach of defining “Category,” a “Type” associated with the “Category,” and an “Item” associated with the “Type.” One popular approach suggests that Category and Type be “nouns,” and Item be a “verb.”
This type of scheme yields classification taxonomy as follows (using CTI taxonomy):
category noun (Database) | type noun (Oracle) | item verb (Upgrade)
Thus, after determining the inquiry is an Incident, not a Request for Change (RFC) or Service Request, and deducing that the Incident relates to an Oracle database requiring an upgrade, the Service Desk staff would then code the Incident as:
Database | Oracle | Upgrade.
However, the CTI approach can limit your effectiveness because there are some not-so-subtle issues with its logic. CTI works well when the work required is known, as in this example. But CTI quickly becomes problematic when the workflow is not well known.
For example, how might a Service Desk agent know the “Database” category required a type called “Oracle?” More importantly, what if there were multiple “Types” of databases – for example, Oracle, SQL, mySQL, and Access? Which one would the Service Desk agent choose?
The extra investigation and diagnosis required to troubleshoot the Incident to complete the CTI classification is precisely the problem with the CTI approach – it complicates data collection and combines Classification and Initial Support with Investigation and Diagnosis, which confuses the purpose of Initial Support.
The reason is simple: CTI assumes a technical understanding of the causes of Incidents, and most Service Desk staff (those performing Classification and Initial Support) will not know the cause of an incident until it progresses through the Investigation and Diagnosis activity, and perhaps until closed.
This type of classification usually occurs when a group of technology specialists determine (on their own) how routing of tickets would work if they could design a system that they would use, to be used by people who know what they know.
Of course, the problem here is that technical staff do not perform Classification and Initial Support; relatively non-technical Service Desk agents do.
In other words, for Service Requests where the workflow is obvious, CTI is fine. However, for Faults or where workflow is not known or obvious CTI can become problematic when used by non-technical agents. Clearly, we need another approach that is less technical, and more flexible.
Let’s go all the way back to what exactly is an Incident. ITIL defines an Incident as:
"Any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service."
This is a pretty large definition that covers two broad types of work:
- Requests for new or additional services
Service requests encompass an additional level of detail. Examples of service requests include:
- Questions about using services (e.g., application queries, often handled at the Service Desk)
- Routine actions (e.g., password resets or Requests, often routed to IT operations and resolved via Standard Changes)
Additionally, the Service Desk, where Incident Management begins, also collects Requests for Change (RFCs) through the Request Fulfillment process. While an RFC is not a type of Incident, the Service Desk has to be able to identify them and handle them as needed, usually to route to Change Management.
This complicates classification a bit, since now we have to determine if the inquiry is a Request and not an Incident; and if an Incident, which type of Incident it represents – Fault or an Application Inquiry (how to use an application or system feature or function.)
Each of the possibilities will take a different path through the IT organization. This truth makes the first entry in the classification taxonomy a Type (e.g., path through IT to a support group) and not a Category (e.g., what must happen when it gets to the right group.)
The Service Desk has to be able to separate user inquiries into one of these bins and then handle each appropriately. Now you begin to see why classification is one of the most frequently asked practitioner questions, and why CTI may not be quite right for everyone approaching Incident classification.
Door Number 2 – ITIL Classification
Classification and Initial support is just for that reason – initial support. Initial support is determining what type of support the customer or user requires. Classification determines the initial support the customer or user requires and this means the first entry in the classification taxonomy must indicate the type of work to be accomplished; it must clearly define how the IT organization must respond (not who in the organization must respond.)
For these reasons, ITIL provides an example of this and labels the first element of its classification taxonomy as “Type.” The Type entry describes the broad functional involvement required to support the customer or user.
There are just a few types based on the previous discussion regarding possible user inquires. The exact number of Types is to be determined, but should clearly represent the major course through the organization. Some examples include:
- Service Request
- Technical Incident
Using a Type element establishes the basis for known work like RFC, Service Request, or fault, and allows differentiating lists for top level or main Categories. Examples of main Categories by Type might include:
- Move/Add/Change to system
- Password reset
- Printer not printing
- System down
- Disk-usage threshold exceeded
- Automatic alert
- Request for information
- Assistance using application
Note how the main category examples provided all report the issue in plain, non-technical, usage-based terminology. Users can only report symptoms of what they experience and request assistance in terms they understand. Note the separate category for non-user reported Incidents – Technical Incident.
After establishing the first element, “Type,” the next element, “Category,” changes based on the Type. For example, considering a Service Request for help and guidance about a software application, a well-formed classification might be (using ITIL taxonomy):
Service Request | Help User | Desktop Application
Now compare how CTI (noun-noun-verb) might write such a work request (using CTI taxonomy):
Software | Desktop Application | Help User
In comparison to CTI, note how the ITIL taxonomy clearly defines the work required of the organization (Service Request, not a Fault), helps the Service Desk agent or subsequent workers know what actions must occur (Help User, nothing to repair), and finally what specialist should engage (Desktop Application). This very clearly communicates how the organization must respond.
Note how the CTI taxonomy looks more like an IT organizational structure than a definition of required support. This is a key failure when using CTI. It is easy to fall into this CTI trap if you lose sight of the fact that Classification and Initial Support is only to understand the support required. Overloading classification with too much technical direction reduces the effectiveness of classification to improve workflow and IT efficiency.
Users only report symptoms relevant to their usage of the service, for example, “unable to print from a Word processing application.” This requires a slightly different and more descriptive taxonomy of Type, major Category, and sub-Category. Consider another ITIL example, this time for a user with an application problem (using ITIL taxonomy):
Fault | Word Processing | Cannot print
Note how the classification describes what the user cannot do, not what the agent thinks the support group has to repair. “Cannot print” is very different from “clear print queue.” Try to avoid classification that gives direction or predicts the failure, focus instead on fully describing in plain words what the customer or user cannot accomplish.
The practical result of CTI vs. ITIL classification is that with ITIL you can have reduced classification tables, and the classification schemes tend to be more “user friendly.” Finally, CTI almost pre-assumes an understanding of root cause and thus where to route the Incident, while ITIL aids routing without trying to diagnose root cause.
Those who favor the CTI approach are usually quite technical. They do not realize the value and limitations of a non-technical “front-end” to the process. These technical types often devise classification schemes that, in addition to including the expected resolution, wind up looking a lot like the support organization (using CTI taxonomy):
Packaged Software | MS Office | Macro Issue
Network Services | Cisco Router | Port locked
When a user calls, it is not yet possible to know what the cause of the Incident is – how would you know this is a “Network Services” or “Packaged Software” issue? In contrast, virtually everyone can talk to a user and determine if the Incident is a fault or a service request; determine which IT service, system or application is in question; and describe what the object of Investigation and Diagnosis ought to be.
In other words, it is more likely to mix Investigation and Diagnosis objectives with Classification and Initial Support objectives when approached from a CTI perspective.
On the other hand, the ITIL approach has flexibility, and assumes that additional data (root cause, Configuration Item identification, etc.) come later during Investigation and Diagnosis, and the only goal of classification is to develop a clear understanding of the issue the user is reporting. Thus, the ITIL method for classification is a “better” choice for most.
Classification does not exist to establish root case or predict technical resolutions but rather to enable Initial Support, and Initial Support determines the workflow through the organization. Classification necessarily becomes more refined as the Incident progresses and more is learned via the Investigation and Diagnosis activities.
Classification schemes and their strategies for establishing types and categories will vary from organization to organization. However, they share some common goals:
- They should always be agreed between IT and the business.
- They should always be agreed between IT groups and the Service Desk.
- They should direct further analysis, evaluation and routing, not attempt to diagnose root cause.
- They should be as simple and easy to use as possible.
- They should view things from a user perspective, not from an IT organization or technology viewpoint.
Even with properly configured service management software, many still struggle with Incident classification. Common problems include:
- Mixing the objectives of “Incident Classification and Initial Support” with those of “Investigation and Diagnosis”;
- Creating classification schemes with too many entries, making it difficult for Service Desk staff to navigate and provide initial support;
- Classification that is too technical, causing service desk agents to guess when trying to convert user reported symptoms into a technical taxonomy;
- Having a classification scheme that looks like an IT operation organizational chart because it attempts to determine and then route to the correct support group.
These problems all reduce the value and effectiveness of classification. However, forewarned is forearmed! Being aware of the issues other practitioners face can make your own journey easier. Be sure to see the related issues of scripting and Incident classification do’s and don’ts as well.