Network Enhancers - "Delivering Beyond Boundaries" Headline Animator

Showing posts with label Best Practices. Show all posts
Showing posts with label Best Practices. Show all posts

Thursday, March 20, 2014

The 7 Habits of Highly Effective EXECUTIVES


You might have read Stephen R. Covey’s top-seller – ‘The 7 habits of highly effective people’. Taking inspiration from the same and adding my own observations and experiences, here are the 7 habits of highly effective executives:

Habit 1: They endeavor for excellence in their domain AND keep track of super performers in their market space

Habit 2: They learn from the past, focus in the present AND lead into the future

Habit 3: They welcome diversity of thought among stakeholders AND collaborate with them to achieve the business objectives

Habit 4: They build dignified relations in their business community AND earn respect among their industry peers

Habit 5: They ascertain performance based on metrics AND differentiate reality from hype

Habit 6: They hold a healthy balance between their individual & business interests AND maintain integrity with their personal values

Habit 7: They foster a learning culture in their organization AND actively seek solutions to overcome challenges faced in their business
 

Wednesday, March 19, 2014

5 Best Practices for Sales Management


The challenge for Sales Managers has been to align the individual sales person’s behaviors to match with the company’s direction.

By driving an ongoing alignment of various teams inside your organization; Sales Managers could increase their business relevance to the customer.

Sales Management Best Practices:

· Provide marketing support services (mailers, brochures, newsletters, social media) for your sales team to develop and close new opportunities

· Empower your sales team with rich context (deeper client and industry insights) for enabling consultative selling

· Align your internal staff for linking your company’s unique capabilities to your customer’s priorities

· Use meaningful content (blogs, whitepapers, informative articles) for stimulating trusted conversations with prospective customers

· Analyze outcomes and make requisite modifications to improve results

 

Sunday, January 26, 2014

10 Tips Along The Path To A Managed Services Model

Checklist For Managed Services Migration


Specifics around a move from traditional resale to a managed services model vary by company, by circumstance and by objective. Most channel companies that have moved in this direction have blazed their own trail, to a large extent. But based on interviews with solution providers, certain practices seem to rise to the top. Here is a list of action items that can serve as a helpful starting point in developing your business transformation methodology.


1. Begin With The Customer

What are your customers' opinions of managed services and cloud-based services? Assess their desire and their willingness to move in this direction, as opposed to maintaining systems on their premises. Pay close attention to who within the organization is in favor of the move and who within the organization is not. You may find that some customers will begin this discussion adamantly opposed to a managed services model, but then become more open to the idea after gaining a better understanding of the business case. This can occur within a single discussion or sometimes over the course of several months. But understanding your customers' willingness is your own first step for developing a strategy.

2. Assess Your Customers' Technology Readiness

Take a look at how each customer is using information technology at the customer premises and begin to draw parallels between those configurations and how the cloud and/or managed services might be used. Develop your own recommendations for what technologies can be easily and safely moved into the managed services model, and be prepared to articulate both the risks and advantages of doing so.

3. Review Your Capabilities

Once you have completed your assessment of customer readiness, look to your own company's capabilities and differentiators. Develop cloud and managed services alternatives for as many of your offerings as possible. It's best for customers to see that your service line includes everything for which you are familiar to them. Develop the capability to function as an evangelist for managed services and cloud-based services. Familiarize yourself with the business case, and understand where it is best deployed, and where on-premise remains the legitimate choice for customers.


4. Assess Your Solutions

Although many established, traditional IT vendors are developing software and services specifically to support the cloud and managed services model, there may be instances in which new vendors that specialize in cloud technologies can be added to your mix. Evaluate everything in terms of fixing business problems by way of technology, rather than selling technology for the sake of technology. Develop underlying methods for becoming familiar with customer business problems that can then be extrapolated to specific solutions.


5. Assess Financial Impacts

Recognize that the move toward cloud and managed services will extend revenue over a lengthy period of time but will reduce the up-front revenue with which traditional resale is associated. Therefore, it is important to make sure that expenses are timed commensurate with the rate at which revenue is collected in order to avoid critical cash flow problems.


6. Establish Management-Level Buy-In

This may be more of an issue at some companies than at others, but the champion of managed services and cloud services within your organization undoubtedly will need support from the executive suite in order to realize the business model migration. A detailed cost/benefit analysis can be augmented by articulating how industry trends are forcing much of the channel in this direction. Therefore, buy-in may not be difficult to achieve. Nonetheless, the executive team will need to see sufficient data to support the move, as well as an efficient and workable strategy for execution.


7. Establish Sales-Level Buy In

Most solution providers familiar with the VAR/integrator business model have sales teams that are highly attuned toward building profitability through the sale of products. A move toward managed services and cloud-related services will force these individuals to reassess their tactics for presenting the value proposition and eventually closing the deal. Some may see this shift as a threatening development. Others will acknowledge the industry trend and actively seek to shift their approach to doing business. Build sales strategies that reflect the new model, and execute those strategies either through your existing sales force or through a new sales force dedicated to managed services. Finally, assess your back-end systems to make sure they can handle a business model based on monthly recurring revenue.


8. Establish A Managed Services Tiger Team

Regardless of how carefully you plan your transition into managed services, there inevitably will be certain factors and developments that were unforeseen or otherwise overlooked. It is important to have a specific "tiger team" charged with navigating and executing the transition's components, regardless of whether they are planned or unplanned. Management representatives should be joined by all the major groups within the organization, including sales, engineering, marketing and operations.


9. Develop A Marketing Strategy

As you near the formalized rollout of your new business model, develop a comprehensive marketing strategy aimed at articulating the benefit to your customers while also demonstrating that your company is the right choice to help them down this path. Very often, solution provider organizations are launched by technologists who understand how to leverage products and services, but are not necessarily experts in the marketing field. It will be important to have such talent on board in order to capture the attention of your customers.


10. Set Benchmarks

Establish a list of key metrics that you intend to track in evaluating the relative success of your transition. Aspects such as customer retention, cost of acquisition and profitability will obviously factor heavily into this equation. But it is also important to see to what extent managed services and cloud services are helping you to extend your footprint, both geographically as well as into new technologies. Make sure to set reasonable benchmarks and objectives.

 

Sunday, May 5, 2013

Four Steps for Optimising Customer Service Operations

 
Customers want efficient, effortless service from the touchpoint and communication channel of their choice. They want to receive accurate, relevant, and complete answers to their questions upon first contact with a company.
 
Forrester data backs this up: Sixty-six percent of customers agree that valuing their time is the most important thing a company can do to provide good service. Forty-five percent of US online adults will abandon their online purchase if they can’t find a quick answer to their question. Why is it so important to deliver on customer expectations? Customer satisfaction correlates to customer loyalty, and loyalty has economic benefits.
 
Forrester calculates that a 10-percentage-point improvement in a company’s customer experience score can translate into more than $1 billion in revenue. Conversely, poor customer experiences are costly: Our data shows that 75% of consumers move to another channel when online service fails, which can incur a cost of many millions of dollars.
 
We also know that it is difficult to deliver customer service in line with customer expectations. Our customer service technology ecosystem is increasingly complex. Social technologies have disrupted traditional communications, and smartphones and tablets have made the delivery of consistent experiences across touchpoints more challenging. And the number of vendor mergers and acquisitions has complicated vendor selection.
 
So how do you do better? Forrester’s customer service playbook details a four-step prescription that can help you out:
 
Discover what matters for customer service. Understand customer-facing, agent-facing, and technology trends that are shaping the future of customer service-trends like changes in communication channel usage by demographic, mobility solutions for customer service, the value of tighter coupling of knowledge management to case management, BPM adoption, the rising importance of outsourcing, cloud-based technologies, and the evolving technology landscape.
 
Plan for improvements. Assess your current operations against best practices to understand your strengths and pinpoint areas of opportunity. This will help you build a concrete plan for improvements and lay out a technology adoption road map. It will help you answer questions such as
“Do I first fix my IVR navigation, launch web self-service, or update my case management solution?”
 
Act on your findings. With your planning in place, it’s time to choose whether to outsource customer service operations and/or technology, buy it from a vendor, or, in unique cases, build it yourself. This decision is very important, as the vendor landscape is broad, mature, and rife with mergers and acquisitions. Partnering with the right technology provider can make or break your operations.
 
Optimise. Customer service is no longer viewed as just a cost centre. Key success metrics have historically focused on productivity, efficiency, and regulatory compliance instead of customer satisfaction. However, forward-thinking organisations are gradually adopting a Balanced Scorecard of metrics that include not only cost and compliance, but also customer satisfaction, which is more suited to drive the right agent behaviour and deliver outcomes better aligned to customer expectations.
 

Wednesday, May 1, 2013

Customer Experience Is Greatest Untapped Source of Profits

Courtesy - Computer world


Analyst firm Forrester claims that customer experience is the greatest untapped source of profits in business today, and that projects commissioned to target this are putting pressure on technology departments.

Harley Manning, co-author of “Outside In: The Power of Putting your Customers at the Centre of your Business”, told Computerworld UK that companies need to rethink how they approach customer experience.

“If you look at customer experience from the perspective of what it can do to decrease your costs, what it can do to increase your revenue, and then look at the return on investment from doing those kind of projects, then the discussion of customer experience happens on a very different level and you realise that is probably the greatest untapped source of profits in business today,” said Manning.

“If you set out to be the best in the world at marketing you would struggle because it is a mature discipline and well understood. However, if you said you are going to focus on providing a better customer experience than your competitors, suddenly you are competing in a different arena.”

Manning said that it is hard to assess your systems internally to understand what impact they are having on the customer’s experience, and as a result the technology department should take an ‘outwards-in’ perspective, whereby it assesses every point at which the customer interacts with the business.

“Take each of those touches that the customer has with your company. Perhaps in a retail location, over the phone, on a website, on a mobile app—looking at whether the underlying people, processes, policies and technologies that contributed to the experience that the customer had at each of those points makes you quickly realise that you have an opportunity to do very specific things with technology to improve that experience,” he said.

Bill Band, principal analyst for Application Development & Delivery at Forrester, agreed with Manning and said that companies are beginning to waken up to the benefits of making customer experience a priority, which is placing pressure on IT departments.

“Improving customer experience is putting new demands on technology departments. In particular, one thing that I have noticed is that the projects that get backing tend to cluster around digital interactions with customers because in this day and age a lot of these revolve around mobile or web.

“As a result, a lot more technology-heavy projects are being commissioned around these customer experiences,” said Band.

“Also, the role of technology employees inside these organisations is changing as companies start to focus more on the customer experience. Technology employees have to become more strategic,” he added.

“There is more of a spotlight being placed on the IT organisation to help execute business strategy. So it’s no longer about maintenance and support, these people are now important strategic assets. A lot of them are moving out of pure IT roles into business technology roles and are moving closer to marketing/sales business units.”

The book will be published on 28 August and includes more than 80 case studies from across 15 industries in 16 countries, including examples from Boeing, E.ON Energy, FedEx, T-Mobile and Virgin Media.
 

Wednesday, February 13, 2013

Best Practices - Data Center Upgrades Without the Downtime

 
The data center reflects the fortunes of the business it supports and, as such, has its own cycle of growth and consolidation. Greater usage and data throughput means more servers and racks; this, in turn, means more heat and power issues, which inevitably lead to a need for upgrades or a consolidation of the center itself. Add to this the emerging environmental and energy-consumption regulations, and it is easy to understand why data center managers find themselves in a state of almost perpetual change. Although a new, purpose-built facility always offers an attractive solution to accommodating these demands, it is in fact rarely an option. Because of the cost and disruption issues associated with new construction, retrofitting and live upgrades account for the vast majority of change in the data center, outpacing new construction by a ratio of around three to one.
So how do you prepare for a successful upgrade without downtime?
 

Think About the Business, Not the IT

 
The first, and most important step is to understand that live upgrade is a business issue rather than an IT issue. The choice of a live upgrade is driven by demands on the business to minimize cost and disruption. Therefore, in this context aligning the planning and preparation for the live upgrade to the business itself is of paramount importance.
This approach is very much in the interests of the business as well. A quick checklist of the risks to core business processes that could stem from a failure in the data center makes a convincing case: communications, email, customer accounts and services, the maintenance of an auditable data trail, and many others should convince any board that a live upgrade is a crucial business project.

Properly Supply the Project

Establishing the live upgrade as something that is not “business as usual” should enable you to avoid the most common mistake made by organizations considering such projects: making the IT department wholly responsible for its planning and execution. To make this mistake represents a failure to understand that an IT department’s inherent strength is its consistency and resilience as a service provider. It does not necessarily follow that the IT department should also offer, from its existing resources, the project and change-management skills that are absolutely essential for a successful upgrade. A live upgrade requires a lot of planning across the business. In fact, the project is usually 80% preparation and 20% execution, and as one CTO said, “If my staff had the time to plan a data center upgrade, then I’d know I was overstaffed!”
 
There are four distinct phases of preparation that must always precede the upgrade itself.
 
Phase One: Communicate
 
Although a properly functioning data center rarely has many visitors, it does have many stakeholders. These stakeholders comprise the various parts of the business that depend on the data center to support their processes, and when you begin to contemplate an upgrade, you must start with a communications program that engages with all of them. The program should also include the contractors, third-party support organizations, the project team and any others who hold responsibility for the data center environment. Identify your stakeholders, tell them how the upgrade project will affect them and win their support.
 
Phase Two: Understand Your Environment
 
A thorough audit of your IT environment will help you gain a deep understanding of the demands of the project. Different technologies have different requirements, so you should not assume one size fits all—for example, hot and cold aisles work well for some servers, but not if they draw air from the side. Some equipment, such as a SAN, is very heavy, so make sure you know what the requirements are and plan accordingly. Similarly, consider cable lengths when planning the equipment layout.
 
Phase Three: Plan the plan
 
For the project to be successful, you need to take the business with you. This means listening and understanding the challenges that your colleagues face across the business and planning the work in manageable chunks to suit their needs as well as your own. As you move from planning to execution, establish site control and ensure there is a statement of work (SOW) for each activity. The best approach is to regularly test and validate the plan and be prepared to compromise.
 
Phase Four: Mitigate the Risk
 
Impact assessments for each element of the work are an invaluable tool for managing risk throughout the project. These assessments should anticipate the effects of the work itself and plan for the dust and rubbish that will inevitably be produced; failure here could present the biggest risk of all. A live upgrade is as much about change management as it is about IT, so if your business has a process you should use it. Additionally, ensure that the data center’s backup regime is reviewed before embarking on the project. This should include a review of its physical and logical security as well and the business continuity plan—after all, the data center is about to become a building site!
 
In conclusion, the live upgrade of a data center is not a business-as-usual activity; a typical project may last 6 to 12 months. The data center must support the business for 6 to 12 years. The years between upgrades will involve significant changes both in technology and best practice, so accessing external resources for the project brings the benefit of state-of-the-art specialist knowledge as well as the additional people needed to get the job done on schedule. External expertise—whether consultants or contractors—should offer project-management skills, specialist knowledge, and data center operations experience as well; after all you don’t want them to deliver you a newly refurbished data center that is impossible to operate!
 

Saturday, September 22, 2012

Go Daddy outage highlights need for network segmentation, visibility

 
What kind of lessons can enterprises draw from the recent Go Daddy outage?
 
While outside influences -- like a distributed denial-of-service (DDoS) attack -- can trigger a network outage, many outages are the result of avoidable network events brought on by system updates or configuration errors.
 
Domain name hosting provider GoDaddy.com recently suffered intermittent network outages that brought down customers' email and websites for six hours. The Go Daddy outage was originally thought to be the work of a DDoS attack, but later was determined to be the result of corrupted router data tables stemming from a series of internal network events. In a message posted on Go Daddy's website, CEO Scott Wagner said the provider wasn't hacked and no customer data was compromised.
 
Go Daddy has since implemented measures to prevent this type of network outage from occurring again, Wagner wrote.
 
Just because network outages are a common occurrence doesn't mean providers and enterprises should go down without a fight and accept an unreliable network. Better visibility, failover plans and network segmentation can help limit the impact of a network outage for an enterprise.
 

GoDaddy outage points out need for network monitoring and visibility

 
Six hours of service interruption is a long time for a popular provider like Go Daddy. Better network visibility could ensure earlier identification of such problems and faster resolution for a provider like Go Daddy and for an internal enterprise network, noted Tim Nichols, vice president of global marketing at New Zealand-based Endace, a network traffic recording and visibility provider.
 
Because so many businesses and customers rely on Go Daddy for connectivity, "[the provider] must invest real money in network visibility and network history tools in order to minimize the time it takes engineers to respond, establish root cause, and repair serious service-affecting problems," he said. That visibility must extend all the way into the changes network administrators make to a network. Because the source of the Go Daddy outage most likely stemmed from a corrupted router updating other router tables incorrectly, better configuration and patch management may have avoided the outage, said John Pironti, president of consultancy IP Architects LLC.
 
But given the reputation of Go Daddy, it is unlikely that one issue -- such as human error resulting in a corrupted update -- triggered the outage, and one solution may not have prevented it.
 
"This was most likely the result of a complicated set of updates or [a] number of controls failing," Pironti noted.
 
Early detection of networking issues is important, especially following any network updates. Enterprises and providers should closely monitor traffic flows and data to spot corruption as soon as possible, he said.
 

Network segmentation, design considerations slashes risk of network outages

 
Careful network design techniques can go a long way in preventing a failure similar to the Go Daddy outage. Network segmentation can lessen the impact of a failed network device, Pironti said.
 
"Outages are a reality, but both enterprises and providers should segment their infrastructure so that no single set of equipment or solutions can impact an entire environment if availably and uptime is the primary business need," Pironti said, noting that greater resiliency should be built into network infrastructure.
 
One method of network segmentation is running multiple, parallel systems -- a network design technique that allows organizations to make necessary updates one at a time in order to limit the risk of impact to the users.
 
"Having failover between the systems in case one should start behaving strangely is important because it allows traffic to be quickly moved to another system that has not been impacted," said Craig Mathias, principal with Ashland, Mass.-based Farpoint Group advisory firm.
 
A highly distributed network architecture is much more likely to survive and bounce back quickly from any type of network failure compared to a monolithic system, Mathias noted.
 
While running parallel systems is an option for an enterprise, it may not be an appropriate solution for a provider like Go Daddy, Pironti said.
 
While enterprises can benefit from segmenting two physical facilities -- what is done in most cases of network segmentation -- it's not clear that parallel systems would have solved the Go Daddy outage because the provider has many facilities, he said.
 

Final Go Daddy outage lesson: Don't single-source providers

 
While providers can adopt technologies and procedures to minimize failure impact to their customers, enterprises do not need to sit idly by while the service provider works out networking issues.
 
"[Enterprises] must understand that they are dealing with complex, imperfect systems that will fail and they do need a contingency plan so they don't become a victim," Mathias said.
 
If availability is a critical factor, enterprises should diversify with multiple providers to ensure a secondary environment in the event of a network outage of one provider, noted IP Architects' Pironti.
 
"The user has to take some responsibility," he added, noting that no provider is too big to fail.
 
Failing over to another provider is one way that enterprises can ensure that business will stay up and running, even though they may not have 100% functionality, noted Farpoint's Mathias.
 
An enterprise considering a multi-provider environment can also benefit from using vendors -- like Akamai Technologies -- that offer load balancing and redundancy between providers, Mathias added.
 
"Enterprises need scalable expansion that allows them to grow, without any single point of failure," he said.
 
 

Saturday, July 14, 2012

Network Operation Center (NOC) Best Practices – Part 3: Processes

This is the third part of our 3-part blog series discussing Network Operation Centers (NOC’s) best practices. The first post was dedicated to NOC tools. The second provided some useful tips regarding NOC knowledge and skills. In this last part, we’ll address processes.

What are the operational, structured processes that you should implement for effective and repeatable results? Here are our top ones.

Escalation

A table of escalation will ensure that all team members are clear on the proper protocol and channels for escalating issues. This table should also include all areas and skills covered by the NOC and the people who are trained to cover those areas.

For example, see the table below defining the escalation procedures for DB related problems.

Time FrameEscalate ToMethod
0+15minsDB on callSMS
0+30minsDB on callPhone
0+60minsDB Group LeaderPhone
0+90minsUNIX & DB Project ManagerSMS
0+120minsUNIX & DB DirectorSMS

A critical problem that was not solved within 30 minutes is escalated up the management ladder, until a response and/or ownership is taken. At every step of the process, it is recommended to involve all personnel up to the current level. So when an SMS is sent to the project manager, it is also sent the DB on call and Group Leader.

Prioritization

The process of prioritizing incidents is different in each NOC, and therefore should be clearly defined. Incidents should never be handled on a first come, first served basis. Instead, the shift manager should prioritize incidents and cases based on the importance and impact on the business. Issues that have a greater impact on the business should obviously be handled first.

Understanding the prioritization of incidents in terms of their business impact should be part of the NOC training. The entire team should be familiar with the NOC “Top 10” projects, and have an understanding of what signifies a critical incident. It could be the temperature rising in the data center, a major network cable breaking or a service going down.

Obviously, common sense is very useful. Clearly the shift leader should be able to determine that an incident that jeopardizes the entire data center has a higher priority than a request to verify why an individual server is down.

Incident handling

The process of handling incidents applies both to NOC operators and shift managers. Both roles should be familiar with the specific process of handling incidents with the greatest impact on users.

Incident handling process should cover issues such as:
  • Full technical solution, if available.
  • Escalation of issue to appropriate personnel.
  • Notification of other users who may be directly or indirectly affected by issues.
  • ‘Quick solution’ procedures or temporary workarounds for more complex problems that may take longer to completely resolve.
  • Incident reporting. An incident report, completed once the incident is resolved, helps improves the service when the next incident occur, or may also prevent the recurrence of the same incident.
Employing the proper tools, skills and processes in your NOC will allow you to run more efficient network operations and ensure smooth day to day operations as well as meeting the demands from the IT department.

Tuesday, July 10, 2012

Network Operation Center (NOC) Best Practices – Part 2: Knowledge & skills


This is the second of our 3 parts blog series discussing Network Operation Centers (NOC’s) best practices. The first post was dedicated to NOC tools. This part is dedicated to knowledge and skills. By ‘knowledge and skills’ we do not mean the obvious technical knowledge, network ‘know-how’ your team members must hold in order to run day-to-day operations, but rather –

How you can ensure your team’s skills are used to their best potential, and how to keep those skills up to date over time.

Clearly define roles

Definition of roles may vary between data centers and will depend on team size, the IT environment and tasks. Still, there should be a clear distinction between the roles and responsibilities of operators vs. shift supervisors in the NOC.

Why does it matter?

Mainly matters because of Decisions making. Without clearly defined roles and responsibilities, a disagreement between operators may lead to late decisions and actions, or to no decisions taken at all. This may affect customers, critical business services, and urgent requests during off hours.
It should be clearly defined, therefore, that a shift manager makes the final decisions.

Tasks division

Another potential problem caused by a lack of role definition is the division of tasks between operators and the shift leader.

A shift manager should be responsible for: prioritizing tasks, assigning work to operators based on their skills, verifying that tickets are opened properly and that relevant personnel are notified when required, escalating problems, communicating with management during important NOC events, sending notifications to the entire organization, preparing reports, and making critical decisions that impact many services, such as shutting down the data center in case of an emergency.

Operators, on the other hand, are responsible for handling the technical aspect of incidents – either independently or by escalating to another team member with the required skills. Operators are also responsible for following up and keep tickets up to date.

While it might sound as if operators lack independence and responsibility, this is not the case. When faced with technical challenges, operators’ input and skills are probably the most critical for resolution and smooth NOC operation. Operators provide additional insights into problems, and can provide creative solutions when the standard procedures fail to work.

Invest in orientation program for new NOC employees

How often have you started a new job, without receiving any orientation, mentoring or guided training?

Failing to provide proper training to new NOC operators always has consequences. A new NOC operator may not know where to find a procedure or how to execute it; be confused about who should handle a task – the NOC, service desk, or higher level of support; or in a more severe case, take a decision that causes equipment damage or results in downtime of critical business services.

Therefore, an extensive training program should be put in place for new NOC employees. This is definitely a challenge, considering the lack of resources, particularly in small NOCs. Ideally, such a program would consist of one week of classroom training followed by three weeks of hands-on training under the supervision of a designated trainer.

A new employee should only be trained by an experienced member of the NOC, preferably a shift leader. The trainer should be released from all duties during the entire period of the training – in order to ensure that the training does not gradually fade between all the urgent shift tasks.

The training program should be updated on an ongoing basis, and should include topics such as required users and permissions, technical knowledge, known problems, troubleshooting, teams and important contacts.

Communication and collaboration

Within your Organization

Establishing a solid communication flow between NOC members and other IT teams has many advantages. It propels professional growth, provides opportunities for advancement in the organization, and makes it easier to approach other teams when requiring assistance. But most importantly – it allows NOC personnel to see the larger picture. NOC members that are aware of projects, services and customers’ needs, simply provide better service.

A designated member of the NOC should attend weekly change management meetings. That person should communicate any issues or upcoming activities, such as planned downtime, to the rest of the team.

Define NOC members as focal points for important IT areas, such as NT, UNIX, Network, or a specific project is another good practice. These members should attend the meetings of the relevant teams, deliver new information and knowledge to the rest of the NOC, and handle specific professional challenges.

Within NOC Team

Another important form of communication is within the NOC team itself. There are clear advantages to having a strong connection and collaboration between NOC team members. Members are more willing to help each other, information is shared more easily, and the general atmosphere encourages collaboration when addressing problems, as opposed to an individualized approach.
Team communication is a challenge when the NOC team is geographically spread out or located in different countries. Because cultural and language differences can cause confusion and misunderstandings, spending efforts on building team communication and collaboration are even more critical.

Wednesday, July 4, 2012

Network Operation Center (NOC) Best Practices – Part 1: Tools

Today, Network Operation Centers (NOC’s) are under a great pressure to meet their IT organization’s demands. However, many NOCs struggle to meet these demands with insufficient tools, knowledge or skills.

In this 3 parts blog post series, we will provide tips on how to ensure you have the right tools, knowledge and processes in place to improve and manage your NOC’s performance and response time.

This first part of our ‘NOC best practices’ series is dedicated to tools, which are an essential element in NOC management and a key feature for improvement.

A ticketing system

A ticketing system will enable you to keep track of all open issues, according to severity, urgency and the person assigned to handle each task. Knowing all pending issues will help you to prioritize the shift’s tasks and provide the best service to your customers.

Knowledge-base system

Keep a one centralized source for all knowledge and documentation that is accessible to your entire team. This knowledge base should be a fluid information source to be continuously updated with experiences and lessons learned for future reference and improvements.

Reporting and measurements

Create reports on a daily and monthly basis. A daily report should include all major incidents of the past 24 hours and a root cause for every resolved incident. This report is useful and essential for the shift leaders and NOC managers. It also keeps the rest of the IT department informed about the NOC activities and of major incidents. Compiling the daily reports into a monthly report will help measure the team’s progress. It will also show areas where improvements can be made or indicate any positive or negative trends in performance.

Monitoring

There are two types of monitoring processes relevant to NOC:
(1) Monitoring infrastructure and (2) User experience.

A monitoring infrastructure can consist of the servers, the network or the data center environment. User experience monitoring involves the simulation of user behavior and activities in order to replicate problems and find the most effective solutions. Implementing a service tree model that connects the monitoring infrastructure with an affected service will allow your team to alert other areas that may be affected by the problems experienced.

IT Process Automation

Implementing IT Process Automation significantly reduces mean time to recovery (MTTR) and helps NOCs meet SLA’s by having a procedure in place to handle incident resolution and to consistently provide high quality response regardless of complexity of the process. IT Process Automation empowers a Level-one team to deal with tasks that otherwise might require a Level-two team. Some examples include password reset, disk space clean-up, reset services etc. IT Process Automation is also a major help with reducing the number of manual, routine IT tasks and free up time for more strategic projects. 

Tuesday, June 19, 2012

Ethernet Patch Cable Colour Codes & Bestpractices

Ethernet Patch Cable Colour Codes


 
Keeping data from getting crossed in a data center can be a pain. Below are some of the standards followed in Data Centers
  • blue - most common so workstations or generic servers.
  • red - critical systems. Sometimes used for building fire systems
  • yellow - less critical system.
  • orange - cabels that go off to other racks
  • green - where the money flows for e-commerce systems.
  • black - VoIP systems since the phones came with blakc patch leads
  • white - video camera network
  • pink - used for rs-232 serial cables
  • purple - used of isdn type links
  • tan - telephone lines  
This is the current list of colors of ethernet cables that can find be found in general ind DC or have seen:

blue
light blue (rare but commonly used on cisco cables)
fluorescent blue (even rarer)
red (many of these are cross over cables)
yellow (this was a standards approved color for cross over cables)
cisco cable yellow
orange
pink
fluorescent pink
green
fluorescent green (never seen this buts its in catalogs)
black (easy to confused with power cords)
white (sort of rare)
light gray
dark gray (rare)
silver (rare)
tan/beige (common in cat 3 patch cables)
purple/violet (they are different but when you order one you get the other)
fluorescent violet (very rare)

 
One thing to consider is about 15% of all males are slighly color blind and only about 10% think they are. Many colors look the same but often times a color blind person can easliy tell the difference between say tan cables and beige cables but can't tell the red from the green.

 
Color codes for fiber (fibre?)

  
Orange - multimode
Yellow- Single mode
gray - could be either but tends to be single mode
light blue - could be either
Color codes for fiber jackets
Blue - Stright cut - fiber joint is perpeneducalr at 90 degrees
Green - Angled cut - fiber joint is angled slightly

Note that buildings will often have these colors:

 
red - fire alarm cables
white - cheaper fire alarm cables
blue - who knows? Could be alarm, fire, hvac, or data
tan - same as blue but older

For -48 volt systems you can get:

 
red - ground.
black - negitive 48V but can routinely be -56V
blue - could be the same as red or black but tends to be the same as red on a differenc circut

 
Note that -48 Volt systems tend to be able to provide massive amounts of unfused current. These system will often have enough capacity to boil the metal in tools.

 
That describes the outer jackets. Inside cables like power you can have:

 
Live power from selected places around the world:

 

red (power Au/UK)
brown (old for AU/NZ/UK)
yellow (old phase 2 UK)
blue (old phase 3 UK)
blue (phase 3 in AU)
blue neutral in Europe
black (power in Europe)
Gray (old IEC phase 3)
gray (power Europe)
gray (neural in US/Japan)
white (neutral in US)
white (pahse 2 in Au)
white (swtich return in AU/UK)
green/yellow - Ground most places
green or yellow but not both (power IEC 60446 and a bad idea)
green (ground in the US according to parts of the Elec code)
green (Never ground in the US according to parts of the Elec code)
bare copper (ground in the US or death)

 
The color codes for ships make much more sense and are about as uniform. For example blue is used for compressed air on US registered ships yet blue is for water on UK registered ships.

 

Tuesday, November 15, 2011

Best Practices for cleaning the Juniper router


1) request system zeroize 

Erase all data, including configuration and log files.  "show system commit" data was not deleted.  On the other hand, all the old configuration files(juniper.conf.[1-3].gz) were deleted and router will came up with the very default configuration.
To deleted "show system commit" information the following technique should be used.

2)
root> start shell sh
# echo "" > /var/db/commits
# exit
3) rm -rf /var/home/*


Saturday, October 22, 2011

Best Practices Part 1 - Layer 2 Spanning-Tree

The topology depicted in the diagrams is used to help demonstrate data flow during failure and to provide discussion around best practices and may not be necessarily be configured as optimal as possible. The examples below will provide alternate technical solutions that follow best practice guidelines.

Topology Image



Normal Data Path Flow

 Data Path Flow Root Fail




Data Path Flow-Access Trunk Fail

Data Path Flow Router Fail





Spanning-Tree mode Rapid-PVST (802.1w) or MST (802.1s) - This will show more about load balancing techniques leveraging each of these technologies in "Layer 2 Spanning-Tree Best Practices Part-2" Deterministic blocked ports - in this example we know exactly which ports are going to be blocked by STP. All redundant connections to the secondary root bridge will be blocked. Cisco also recommends that you do not exceed STP diameter of seven hops. Ensure that you hard configure your Root and Secondary Root bridges. Ensure that you only allow required VLAN's over the trunks to ensure you are not running unnecessary STP instances.

Features to leverage include:
Access Layer
-portfast
-bdpuguard
-disable DTP
-loopguard
-etherchannel Guard

Distribution Layer
-root and secondary root placement
-root guard
-disable DTP
-etherchannel Guard

Leverage EtherChannel to reduce the number of ports that need to transition from blocking to forwarding state when leveraging multiple links.

EtherChannel Ports
-EtherChannel Guard



Example:
Access Switch
spanning-tree mode rapid-pvst
spanning-tree priority vlan 1-4094 61440
spanning-tree portfast bpduguard default
spanning-tree loopguard default

interface gig x/x
description Link-to-RootBridge
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 10,11
switchport nonegotiate

interface gig x/x
description Link-to-SecondaryBridge
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 10,11
switchport nonnegotiate

interface gig x/x
description Link-to-Server
switchport mode access
switchport access vlan 10
switchport nonnegotiate
spanning-tree portfast

Distribution Switch
spanning-tree etherchannel guard misconfig
spanning-tree mode rapid-pvst
spanning-tree priority vlan 1-4094 0
spanning-tree portfast bpduguard default

interface gig x/x
description Link-to-AccessSwitch
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 10,11
switchport nonnegotiate
spanning-tree guard root

interface port-channel 1
description Link-to-SecondaryRoot
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 10,11,12,13,14
switchport nonegotiate
spanning-tree guard root

interface gig x/x
description Link-to-SecondaryRoot-1
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 10,11,12,13,14
spanning-tree guard root
switchport nonegotiate
channel-group 1 mode active

interface gig x/x
description Link-to-SecondaryRoot-2
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 10,11,12,13,14
spanning-tree guard root
switchport nonegotiate
channel-group 1 mode active

My Blog List

Networking Domain Jobs