Saturday, December 22, 2012
Business Lesson 'Impossible'
Here's my analysis of each show
Restaurant Impossible
Businesses Type Fixed: Single Location Restaurant
Primary Product: A meal served
Primary Financial Issue: Food cost
Common Problems: Poor financial management, poor kitchen management, poor personnel supervision
Common Management Issue (almost every episode): Owner/Manager doesn't understand the the restaurant business
Bar Rescue
Businesses Type Fixed: Single Location Bar
Primary Product: A good time for adults
Primary Financial Issue: Liquor cost
Common Problems: Poor financial management, poor bar management, poor personnel supervision
Common Management Issue (almost every episode): General Manager (may be the owner) doesn't understand the bar business.
Other Observations:
While a bar and a restaurant may seem similar and may provide the same products (food and liquor), what the customer is buying is very different. In one case it's a meal served to you at your table, in the other case its a social environment and atmosphere. In the case of a restaurant the food is a critical component, at a bar the atmosphere is critical.
On both shows usually the employees know what the problems are, but the managers won't listen to them.
Some Lessons Learned
1. Understand the business you are in. In just about every case, the person running the business never ran a business of the sort they are trying to run. They are completely lost as to the basics, not because they are incompetent, but because they have no idea what to do. Just because you are a customer of a business doesn't mean you can run it.
2. Solicit feedback from, and listen to your employees. Your employees usually know a lot about whats wrong with a business.
3. Understand the key drivers of your business. What is your customer really buying ? What are your cost and price drivers? What should your staff be doing ?
Monday, December 3, 2012
Stupid Interview tricks
- Putting stuff on your resume you can't support. Be prepared to give examples/descriptions/details of EVERYTHING you wrote on your resume. Its likely that we chose to interview because of some of those things, If you didn't do them, your probably out.
- Not being able to answer the 'strengths and weaknesses' questions. Yes it is a trite question, but we are going to ask it, so have an answer. If you can't answer that question, all it shows is that you are not prepared.
- Its not about you. We want to know what you did to help your former company and co-workers, not what you did to help yourself.
- Don't come in without doing some research on the company, the more the better, it shows you care.
- Don't badmouth former employers. We don't like to work with bitter people.
- Don't say stuff like my passion is [something not related to the position you are interviewing for]. We want people passionate about the job we are interviewing for.
Sunday, December 2, 2012
I Hate Best Practices
Definition of Best: That which is the most excellent, outstanding, or desirable. (Google)
I don't hate the concept, just the term. Best implies that there is none better, and that therefore it should always be used.
So this means that we should all use this practice. (It would be stupid not to if is the best). Of course this would mean we would all be doing the same thing there would be no competitive advantage.
Besides is there really such thing as a singular best way to do anything ? If there was, than we would never have to improve upon it. I do believe that leaches were a 'best practice' of medicine in the middle ages.
Ok, so all you Best Practice people are going to tell me "No that's not what we mean, we mean that these are good ideas to look at, to see if you can apply some or all of them to your situation." So you are saying they are not the best. But I guess that good-ideas-to-look-at-to-see-if-you-can-apply-some-or-all-of-them-to-your-situation practices is too long to put on a business card. They were best somewhere for some period of time so we will just call them Best Practices even if its inaccurate. Besides it will sell more consulting hours anyway.
Who needs clarity in communication.
Saturday, November 10, 2012
Fixing my fence, the ITIL way
- Event--> Dogs barking outside.
- Alert --> Dogs shouldn't be barking this early .
- Incident Created with service desk --> Dogs shouldn't be barking this early.
- Incident Troubleshooting Dog is outside the fence, Fence SLA violated ('5 Nines' Dog Containment)
- Incident Priority Critical.
- Transferred to Problem Management.
- Problem Management identifies a work around --> Put the the dog in the house.
- Problem Management communicate the work around to service desk to communicate to customer.
- Dog is put in the house.
- Since the Fence is a VBF and the SLA is being violated Problem Management convenes the ECAB
- Problem Management identifies the problem and suggests a solution --> Fix the section of the fence that dog breached.
- The ECAB Approves the change and transfers it the Technical Operations.
- Technical Operations fixes the problem.
- The Change is noted in the CMDB (My Wife).
- The Service Desk is notified, they notify the customer.
- The dog is let back out.
- During Post incident review by CSI, it's noted that fence inspection should happen more often.
Sunday, November 4, 2012
Does Microsoft Really Understand Tablets
Friday, November 2, 2012
XML, Just Say No.
Sunday, October 28, 2012
Everyone is an Entrepreneur
Sunday, October 21, 2012
Professional Development
But one thing that is obviously missing is formal education. For a long time, I figured that formal knowledge really wasn't that important ,as long as I could do my job. Recently, I've concluded that my knowledge is more spotty then I had imagined, And I have begun to to try to fill in the blanks. To be able to talk with my peers, I need not only to know how to do the job, but also the terminology. Frequently, I have discovered, there are tools and methods that I wasn't aware of, that could have helped along the way, had I actually gone to a class on the subject sooner. I've worked hard recently on professional development, because I need to fill in the holes.
Don't skimp on professional development, especially if you are a product of early days of IT. You may have a lot of experience, but there are most certainly holes in your knowledge.
Sunday, October 7, 2012
The end of paper as we know it.
Since the 13th century paper as been used for record keeping and communication. Paper has some very unique properties made it successful for 700 years. It's light, cheap, easy to add data to (writing), data can be retrieved easily by anyone without special equipment (reading), and its durable. These properties made it the go-to method for record keeping and communication. Its biggest disadvantage was that if you want to see the data, you have to go to it or have it brought to you. Reports were written on paper, if you needed to collect metrics, someone reviewed the paper, made calculations and wrote it on a new piece of paper. Paper was so important to the successful operation of society, that the governments created agencies to transport paper under protection of the law (postal service), and other laws to protect content (copyrights).
Enter the late 20th and Early 21st century. The ability of computers to process and disseminate information have relegated data that used to be stored on paper to databases and file systems. Information that used to be disseminated on paper is now transmitted digitally. 50 years ago business records like invoices and customers data were stored in file cabinets, now they are stored in databases. Paper is not just another method to display content.
While this revolution has allowed us to make great advances in almost every field of human endeavor, it has also led to new challenges. Age old institutions are searching for relevance (the postal service); hundreds of years of legal precedents no longer are relevant (copyright). Most importantly, since access to data is governed by technology, as that technology progresses we run the risk of loosing information forever.
We are moving into a new age, we need to start thinking about how we will manage data for ourselves and future generations.
Monday, September 17, 2012
It's The Data, Stupid
I'd like to remind everyone, that the reason we write, software, mobile apps, and even have the Internet is so we can provide information (useful data) to users. Social media isn't about the interface its about the data, the interface just improves access. E-commerce is about moving item data to the customer, and order data to the vendor. This blog is about the information I provide, not the layout. If we loose site of the data, all we end up with is eye candy.
Wednesday, June 27, 2012
Modes of Thinking
Spacial Thinkers. Look at the entire issue, analyze causes and options, to come up with the 'best' solution. They solve structured problems a bit slower, but can solve complex problems quicker than others.
Chaotic Thinkers. Get distracted by some element of the issue and solve a different problem. They are able to solve problems that have not been defined yet.
Examples
A linear thinker walks into a dark room and flips on the light switch.
A spacial thinker walks into a dark room and observes that it's dark, this may mean that the ligh bulb blew out, the power is out, or the light switch is off. She takes a metal inventory of light bulbs and flashlights. Then she flips on the light switch.
A chaotic thinker walks into a dark room , it reminds him of his youth when he used to develop photographs ( old school) in a darkroom. He turns around gets his camera and takes some photos of local landscapes. He later hangs the photos on a blank wall in the currently dark room.
What kind of thinker are you?
Sunday, April 29, 2012
6 Reasons to use a SQL Database
- They abstract data the way that we would store them without a database. A ledger is like a table, an invoice is a one-to-many relationship. They are easy to understand and apply to real life situations.
- They are structured. Since each row in a table has the same structure, you only have to write one 'piece' of code to deal with it. Less code means faster development times, and less bugs.
- Static Data Types. Each column has a static data type (Or should anyway) so programs don't have to worry about data validation when retrieving data. This means less code too.
- SQL. They all run a dialect of SQL which cuts down on the programming learning curve.
- They are reliable. ACID transaction handling means that there is less chance of data corruption. And we all know corruption is bad.
- They are mature. Oracle and DB2 have been around for over 30 years, SQL Server for more than 20, PosgressSQL more than 15. Most of the bugs are out of the system, and there is a lot of documentation available.
Don't jump into the NoSQL pool, unless you need too. SQL RDBMS's still provide the an excellent solution to most data storage and retrieval issues.
Tuesday, April 3, 2012
Valid vs Accurate
Validity in terms of data, means that it fits fits the definition for a particular type of data, for instance, in the case of US dollars it is a decimal number with two places of precision after the decimal point, an US phone number with area code is minimally a 10 digit integer. The other notable property of data validity is that it can be checked with a self contained rule, there is no need to compare it to outside data.
Accuracy, on the other hand, means the data is correct. For instance, the actual value of my electric bill. Accuracy has to be checked by comparison with an outside value, so accuracy checks cannot be self contained. While accurate data is usually valid it does not have to be. If my actual electric bill was 150, it could conceivably presented as in integer instead of a decimal thus making it invalid.
When dealing with data, make sure that you deal with validity first, followed by accuracy. This is especially true with weakly typed languages and variant data types.
Wednesday, March 14, 2012
Getting out of your programming comfort zone
As you may know if you are writing a basic report there are three key parts of a SQL statement the SELECT clause, where you output goes, the FROM clause where your table and table relationships go, and the WHERE clause where you choose what data you want to display. (Yes, I know there's ORDER BY, GROUP BY, UNION, etc, but I'm trying to make a point not teach anybody SQL.) What I have discovered is that I've been subtly trapped in this paradigm. If it needs to be output its in the SELECT clause, if it needs to be chosen its in the FROM clause, I may nest SQL statements, but in the end I'm stuck in this single statement framework
I've been able to continue on in with this narrow perspective because, if I may say so myself, I'm pretty good at improvising and finding work arounds, so why should I try something new (its not like I don't know about this stuff), when this works. And besides multiple statements, table variables, where loops, if-then statements, and the like are for something more sophisticated than just reports. And doing it this way does work, but sometimes it's slow, confusing, or just downright frustrating. This week I got past that and wrote a report with multiple statements, table variables, a where loop, and an if-then statements, and it was quite enlightening. I'll never look at SQL the same way, and hopefully I'll remember that there may be more to whatever language I'm using at the time then what I'm working with now. So, perhaps I should climb out of my comfort zone and look around.
P.S. Yes, I'm know I'm a geek because I get excited learning new programming language elements.